From Anthony.Petrov at Sun.COM Fri May 1 03:43:51 2009 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Fri, 01 May 2009 14:43:51 +0400 Subject: M3 stabilization requests for 2009/4/30 In-Reply-To: <49FA27CC.9040101@sun.com> References: <20090430214337.E8A8B5CE0@eggemoggin.niobe.net> <49FA27CC.9040101@sun.com> Message-ID: <49FAD267.4080504@sun.com> On 5/1/2009 2:35 AM Phil Race wrote: >> -> 6812298 anthony.petrov Dynamic GraphicsConfig changes don't >> work on >> -> X11 platforms >> >> Phil, if you consider this one super safe and unlikely to cause >> regressions I'd take it in, Marina is the Linux/OpenSolaris release >> and these bugs seem to significantly impact these platforms. > I don't know if I go so far as to call it super-safe. >> If we could get it in b58 it would be better. > Too late for b58. I guess this is a no unless there's a better > justification for the risk and more explanation of the impact. The new API for the shaped/transparent windows introduced in b57 claims it automatically adjusts the graphics configuration for a window when the window is turned transparent via its setBackground() method. This works pretty fine on Windows but not on X11. W/o this fix on Linux/Solaris one should pick up a correct GC *before* they create the window, which: a) isn't handy; b) somewhat does not conform to the spec of the setBackground(). The FX team is way concerned about this particular case - it's not convenient for them to specify the gc before they create the window. Risk: I would rate it low. The fix indeed is quite simple: the only significant change is that on X11 if the visual of the GC gets changed, we just call the removeNotify()/addNotify() pair on the window immediately after updating the GC, which seems pretty safe. -- best regards, Anthony From mr at sun.com Mon May 4 08:32:55 2009 From: mr at sun.com (Mark Reinhold) Date: Mon, 04 May 2009 08:32:55 -0700 Subject: M3 stabilization requests for 2009/4/30 - results In-Reply-To: mr@sun.com; Thu, 30 Apr 2009 14:43:37 PDT; <20090430214337.E8A8B5CE0@eggemoggin.niobe.net> Message-ID: <20090504153255.B2F315E96@eggemoggin.niobe.net> I'm approving these changes for M3: 6834177 vladimir.kozlov Running jsynprog on Solaris Nevada can cause JVM crash 6834246 alan.bateman (ch) AsynchronousSocketChannel#write completes with wrong number of bytes written under load (win) 6762511 anthony.petrov Translucency is not working on Linux using Metacity These changes, however, can wait until M4: 6794764 artem.ananiev Translucent windows are completely repainted on every paint event, on Windows Non-critical performance fix. 6812298 anthony.petrov Dynamic GraphicsConfig changes don't work on X11 platforms A nontrivial fix to the shaped/translucent-window feature, which is not critical for M3 nor for the upcoming FX release, which will be running primarily on JDK 6. - Mark From mr at sun.com Mon May 4 12:52:32 2009 From: mr at sun.com (Mark Reinhold) Date: Mon, 04 May 2009 12:52:32 -0700 Subject: M3 stabilization requests for 2009/5/4 Message-ID: <20090504195232.3616A5E96@eggemoggin.niobe.net> Today we have (so far): 6529590 tim.bell flaw in com.sun.corba.se.impl.presentation.rmi.IDLNameTranslatorImpl 6658163 tim.bell txw2.DatatypeWriter.BUILDIN is a mutable static (findbugs) 6658158 tim.bell Mutable statics in SAAJ (findbugs) 6588002 tim.bell XSLTProcessorApplet still allows reading from forbidden URLs These are all forward ports of fixes already applied to 6uX update releases, and already published in OpenJDK 6. I'll approve all of these at 4:00pm PDT unless I hear objections. There is also: 6829189 john.rose Java programming with JSR 292 needs language support which I'll approve right now since we've previously discussed it. - Mark From Joe.Darcy at Sun.COM Mon May 4 13:06:30 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Mon, 04 May 2009 13:06:30 -0700 Subject: M3 stabilization requests for 2009/5/4 In-Reply-To: <20090504195232.3616A5E96@eggemoggin.niobe.net> References: <20090504195232.3616A5E96@eggemoggin.niobe.net> Message-ID: <49FF4AC6.8080702@sun.com> Mark Reinhold wrote: > Today we have (so far): > > 6529590 tim.bell flaw in com.sun.corba.se.impl.presentation.rmi.IDLNameTranslatorImpl > > 6658163 tim.bell txw2.DatatypeWriter.BUILDIN is a mutable static (findbugs) > > 6658158 tim.bell Mutable statics in SAAJ (findbugs) > > 6588002 tim.bell XSLTProcessorApplet still allows reading from forbidden URLs > > These are all forward ports of fixes already applied to 6uX update > releases, and already published in OpenJDK 6. > > I'll approve all of these at 4:00pm PDT unless I hear objections. > Those are all fine by me. -Joe > There is also: > > 6829189 john.rose Java programming with JSR 292 needs language support > > which I'll approve right now since we've previously discussed it. > > - Mark > From vita.santrucek at sun.com Mon May 4 13:13:50 2009 From: vita.santrucek at sun.com (Vita Santrucek) Date: Mon, 04 May 2009 13:13:50 -0700 (PDT) Subject: M3 stabilization requests for 2009/5/4 In-Reply-To: <49FF4AC6.8080702@sun.com> References: <20090504195232.3616A5E96@eggemoggin.niobe.net> <49FF4AC6.8080702@sun.com> Message-ID: GO for all of them from me as well. Vita On Mon, 4 May 2009, Joseph D. Darcy wrote: ->Date: Mon, 04 May 2009 13:06:30 -0700 ->From: Joseph D. Darcy ->To: Mark Reinhold ->Cc: jdk7-rt at openjdk.java.net ->Subject: Re: M3 stabilization requests for 2009/5/4 -> ->Mark Reinhold wrote: ->> Today we have (so far): ->> ->> 6529590 tim.bell flaw in ->> com.sun.corba.se.impl.presentation.rmi.IDLNameTranslatorImpl ->> ->> 6658163 tim.bell txw2.DatatypeWriter.BUILDIN is a mutable static ->> (findbugs) ->> ->> 6658158 tim.bell Mutable statics in SAAJ (findbugs) ->> ->> 6588002 tim.bell XSLTProcessorApplet still allows reading from forbidden ->> URLs ->> ->> These are all forward ports of fixes already applied to 6uX update ->> releases, and already published in OpenJDK 6. ->> ->> I'll approve all of these at 4:00pm PDT unless I hear objections. ->> -> ->Those are all fine by me. -> ->-Joe -> ->> There is also: ->> ->> 6829189 john.rose Java programming with JSR 292 needs language support ->> ->> which I'll approve right now since we've previously discussed it. ->> ->> - Mark ->> From mr at sun.com Tue May 5 09:22:53 2009 From: mr at sun.com (Mark Reinhold) Date: Tue, 05 May 2009 09:22:53 -0700 Subject: M3 stabilization requests for 2009/5/5 Message-ID: <20090505162253.D05605591@eggemoggin.niobe.net> Today we have: 6819098 igor.veresov G1: reduce RSet scanning times 6829013 antonios.printe G1: set the default value of G1VerifyConcMarkPrintReachable to false Paul says: Two G1 fixes, independent of anything but G1. G1 is experimental at the moment, but we'd like to put our best foot forward. All G1 fixes have gone into hs14 and hs15 so far, including these. I'm inclined to approve these, as long as they make b59. We're not going to have a b60 unless we absolutely have to. 6831225 kelly.ohair Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9) A JPRT (Sun's internal build farm) metadata fix, which doesn't actually affect non-JPRT builds. Parts of this have already gone into other repos. I'll approve this one right now. 6835796 vladimir.kozlov Fedora 9 linux_i586-fastdebug-c2-runThese_Xcomp times out A workaround for a gcc 4.3.0 optimizer bug; it just disables optimization for one file. Low risk -- I'm inclined to approve it. 6837004 artem.ananiev java.awt.GraphicsDevice.setFullScreenWindow throws NPE for windows with background color not set This doesn't seem critical for M3, but it looks like a simple change. Phil, Vita -- what do you think? Comments by 4pm PDT please. - Mark From Phil.Race at Sun.COM Tue May 5 10:04:47 2009 From: Phil.Race at Sun.COM (Phil Race) Date: Tue, 05 May 2009 10:04:47 -0700 Subject: M3 stabilization requests for 2009/5/5 In-Reply-To: <20090505162253.D05605591@eggemoggin.niobe.net> References: <20090505162253.D05605591@eggemoggin.niobe.net> Message-ID: <4A0071AF.9090600@sun.com> Mark Reinhold wrote: > Today we have: > > 6819098 igor.veresov G1: reduce RSet scanning times > > 6829013 antonios.printe G1: set the default value of > G1VerifyConcMarkPrintReachable to false > > Paul says: Two G1 fixes, independent of anything but G1. G1 is > experimental at the moment, but we'd like to put our best foot forward. > All G1 fixes have gone into hs14 and hs15 so far, including these. > > I'm inclined to approve these, as long as they make b59. We're not going > to have a b60 unless we absolutely have to. I agree on this. > > 6831225 kelly.ohair Upgrade JPRT jobs to use newer Linux 2.6 > (e.g. Fedora 9) > > A JPRT (Sun's internal build farm) metadata fix, which doesn't actually > affect non-JPRT builds. Parts of this have already gone into other > repos. I'll approve this one right now. > > 6835796 vladimir.kozlov Fedora 9 linux_i586-fastdebug-c2-runThese_Xcomp > times out > > A workaround for a gcc 4.3.0 optimizer bug; it just disables optimization > for one file. Low risk -- I'm inclined to approve it. > > 6837004 artem.ananiev java.awt.GraphicsDevice.setFullScreenWindow > throws NPE for windows with background color > not set > > This doesn't seem critical for M3, but it looks like a simple change. > Phil, Vita -- what do you think? I think its clearly safe, so I'd allow it for b59. I believe AWT freeze today for b59, however since there's only one other AWT b59 fix, I expect a shorter PIT cycle is doable, but we should make it clear its a b59 approval, not a b60 one. -phil. > > Comments by 4pm PDT please. > > - Mark From Joe.Darcy at Sun.COM Tue May 5 12:37:19 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Tue, 05 May 2009 12:37:19 -0700 Subject: M3 stabilization requests for 2009/5/5 In-Reply-To: <4A0071AF.9090600@sun.com> References: <20090505162253.D05605591@eggemoggin.niobe.net> <4A0071AF.9090600@sun.com> Message-ID: <4A00956F.2020604@sun.com> Phil Race wrote: > > > Mark Reinhold wrote: >> Today we have: >> >> 6819098 igor.veresov G1: reduce RSet scanning times >> >> 6829013 antonios.printe G1: set the default value of >> G1VerifyConcMarkPrintReachable to false >> >> Paul says: Two G1 fixes, independent of anything but G1. G1 is >> experimental at the moment, but we'd like to put our best foot forward. >> All G1 fixes have gone into hs14 and hs15 so far, including these. >> >> I'm inclined to approve these, as long as they make b59. We're not >> going >> to have a b60 unless we absolutely have to. > > I agree on this. > >> >> 6831225 kelly.ohair Upgrade JPRT jobs to use newer Linux 2.6 >> (e.g. Fedora 9) >> >> A JPRT (Sun's internal build farm) metadata fix, which doesn't actually >> affect non-JPRT builds. Parts of this have already gone into other >> repos. I'll approve this one right now. >> >> 6835796 vladimir.kozlov Fedora 9 >> linux_i586-fastdebug-c2-runThese_Xcomp >> times out >> >> A workaround for a gcc 4.3.0 optimizer bug; it just disables >> optimization >> for one file. Low risk -- I'm inclined to approve it. >> >> 6837004 artem.ananiev java.awt.GraphicsDevice.setFullScreenWindow >> throws NPE for windows with background color >> not set >> >> This doesn't seem critical for M3, but it looks like a simple change. >> Phil, Vita -- what do you think? > > I think its clearly safe, so I'd allow it for b59. I believe AWT > freeze today for b59, however since there's only one other AWT b59 fix, I > expect a shorter PIT cycle is doable, but we should make it clear > its a b59 approval, not a b60 one. > > -phil. > >> >> Comments by 4pm PDT please. >> >> - Mark All these changes sound fine to me too. -Joe From mr at sun.com Tue May 5 16:16:29 2009 From: mr at sun.com (Mark Reinhold) Date: Tue, 05 May 2009 16:16:29 -0700 Subject: M3 stabilization requests for 2009/5/5 In-Reply-To: joe.darcy@sun.com; Tue, 05 May 2009 12:37:19 PDT; <4A00956F.2020604@sun.com> Message-ID: <20090505231629.8A8775CE0@eggemoggin.niobe.net> Thanks for the input. I've approved all of today's requests. - Mark From Paul.Hohensee at Sun.COM Wed May 6 12:59:52 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Wed, 06 May 2009 15:59:52 -0400 Subject: 3 more Hotspot approval requests for b59 Message-ID: <4A01EC38.7070602@sun.com> 6829234: Refix 6822407 and 6812971 Fix for a fix in the Serviceability Agent. 6837224: libsaproc.so on linux needs version of 6799141 Serviceability Agent linux build fix. 6833879: Assigning positive zero is ignored when old value is negative zero Language correctness fix. Low risk, since it just disables an optimization. 6833576: G1: assert illegal index, growableArray.hpp:186 G1-only fix. Could hit the assert during fastdebug QA, could segv in product vm if pointer arithmetic produces garbage. Thanks, Paul From Paul.Hohensee at Sun.COM Wed May 6 14:04:56 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Wed, 06 May 2009 17:04:56 -0400 Subject: Another hotspot fix approval request Message-ID: <4A01FB78.2050300@sun.com> 6838154: make/linux/makefiles/sa.make needs hash-style fix The fix for 6837224:libsaproc.so on linux needs version of 6799141 turns out to be partial. This one completes it. Paul From Paul.Hohensee at Sun.COM Thu May 7 08:00:25 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Thu, 07 May 2009 11:00:25 -0400 Subject: Hotspot bug approval request Message-ID: <4A02F789.6010400@sun.com> 6837011: SIGSEGV in PhaseIdealLoop in 32bit jvm Small, low risk change. Paul From mr at sun.com Thu May 7 08:21:53 2009 From: mr at sun.com (Mark Reinhold) Date: Thu, 07 May 2009 08:21:53 -0700 Subject: Hotspot bug approval request In-Reply-To: paul.hohensee@sun.com; Thu, 07 May 2009 11:00:25 EDT; <4A02F789.6010400@sun.com> Message-ID: <20090507152153.F25DA5E96@eggemoggin.niobe.net> > Date: Thu, 07 May 2009 11:00:25 -0400 > From: paul.hohensee at sun.com > 6837011: SIGSEGV in PhaseIdealLoop in 32bit jvm Please make sure that proposed changes have the m3-request keyword. This one doesn't. Looking at the summary page [1] is a much easier way to keep track of things, and makes it less likely that we'll overlook a request. Thanks, - Mark [1] http://cr.openjdk.java.net/jdk7/m3/ From mr at sun.com Thu May 7 08:50:43 2009 From: mr at sun.com (Mark Reinhold) Date: Thu, 07 May 2009 08:50:43 -0700 Subject: M3 stabilization requests for 2009/5/7 (b59) Message-ID: <20090507155043.76E5A5E96@eggemoggin.niobe.net> Today we have: 6829234 poonam.bajaj Refix 6822407 and 6812971 Paul says: Fix for a fix in the Serviceability Agent. This only affects that component; okay. 6833576 john.cuthbertso G1: assert(0 <= i && i < _len,"illegal index") utilities/growableArray.hpp:186 Paul says: G1-only fix. Could hit the assert during fastdebug QA, could segv in product vm if pointer arithmetic produces garbage. G1-only, so this works for me. 6833879 changpeng.fang Assigning positive zero is ignored when old value is negative zero Paul says: Language correctness fix. Low risk, since it just disables an optimization. Hmm; I'm nervous about changing anything in the opto code, but this does indeed look low-risk, so okay. 6837011 christian.thali SIGSEGV in PhaseIdealLoop in 32bit jvm Paul says: Small, low risk change Okay. 6837224 thomas.rodrigue libsaproc.so on linux needs version of 6799141 Paul says: Serviceability Agent linux build fix. SA-only, okay. 6838154 thomas.rodrigue make/linux/makefiles/sa.make needs hash-style fix Paul says: The fix for 6837224:libsaproc.so on linux needs version of 6799141 turns out to be partial. This one completes it. SA-only, okay. 6837982 christopher.heg SCTP API docs not being generated Only affects docs build. Okay. Since most of these requests have been around since yesterday, except the last which is only a docs-build bug, I'll go ahead and approve them all unless someone raises an objection by 10am PDT. - Mark From Christopher.Hegarty at Sun.COM Thu May 7 08:53:51 2009 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Thu, 07 May 2009 16:53:51 +0100 Subject: Approval Request for 6837982 Message-ID: <4A03040F.30906@Sun.COM> Hi Release Team, I would like to try and get CR 6837982 into M3 (b58/b59). The change is simply to the docs Makefile so that the SCTP API [1] docs are generated. m3-request has been added as a keyword. CR 6837982: SCTP API docs not being generated. Webrev: http://cr.openjdk.java.net/~chegar/6837982/webrev.01/webrev/ Thanks, -Chris. [1] http://openjdk.java.net/projects/jdk7/features/#f405 From mr at sun.com Thu May 7 09:42:10 2009 From: mr at sun.com (Mark Reinhold) Date: Thu, 07 May 2009 09:42:10 -0700 Subject: Approval Request for 6837982 In-Reply-To: christopher.hegarty@sun.com; Thu, 07 May 2009 16:53:51 BST; <4A03040F.30906@Sun.COM> Message-ID: <20090507164210.0F7275E96@eggemoggin.niobe.net> > Date: Thu, 07 May 2009 16:53:51 +0100 > From: christopher.hegarty at sun.com > > I would like to try and get CR 6837982 into M3 (b58/b59). The change is > simply to the docs Makefile so that the SCTP API [1] docs are generated. > m3-request has been added as a keyword. Your request is already on our docket from this morning [1]. I expect to approve it in about half an hour unless someone objects. In general there's no need to send requests directly to the Release Team; just add the m3-request keyword and we'll see it. I usually send out a summary of pending requests every morning and make decisions by 4pm PDT. - Mark [1] http://mail.openjdk.java.net/pipermail/jdk7-rt/2009-May/000017.html From mr at sun.com Thu May 7 12:25:18 2009 From: mr at sun.com (Mark Reinhold) Date: Thu, 07 May 2009 12:25:18 -0700 Subject: M3 stabilization requests for 2009/5/7 (b58) [part 2] Message-ID: <20090507192518.F35A85E96@eggemoggin.niobe.net> These just came in, and Xiomara would like to get them into b58. 6829575 kelly.ohair 100028: Debug information is incomplete or missing 6832141 kelly.ohair Bug 100045 - Fix for 100028 breaks debug info for class files 6837665 kelly.ohair Deal with windows ant problem where commas in -D options do not work These are all worthwhile fixes, but I'm a bit nervous about changing makefiles so late in the game. The second two bugs above are fixes to the first -- which is no criticism of either Andrew or Kelly, it's just a consequence of the complexity of our build system and the size of the supported-platform matrix. If there are more problems lurking then we only have one more build in which to find and fix them. So at the moment I'm leaning against these. Comments? - Mark From Phil.Race at Sun.COM Thu May 7 12:30:54 2009 From: Phil.Race at Sun.COM (Phil Race) Date: Thu, 07 May 2009 12:30:54 -0700 Subject: M3 stabilization requests for 2009/5/7 (b58) [part 2] In-Reply-To: <20090507192518.F35A85E96@eggemoggin.niobe.net> References: <20090507192518.F35A85E96@eggemoggin.niobe.net> Message-ID: <4A0336EE.1030408@sun.com> 6829575/100028 doesn't seem like a priority for M3, so I'd say no which means we don't need the other two either .. -phil. Mark Reinhold wrote: > These just came in, and Xiomara would like to get them into b58. > > 6829575 kelly.ohair 100028: Debug information is incomplete or > missing > > 6832141 kelly.ohair Bug 100045 - Fix for 100028 breaks debug info for > class files > > 6837665 kelly.ohair Deal with windows ant problem where commas in -D > options do not work > > These are all worthwhile fixes, but I'm a bit nervous about changing > makefiles so late in the game. The second two bugs above are fixes to > the first -- which is no criticism of either Andrew or Kelly, it's just > a consequence of the complexity of our build system and the size of the > supported-platform matrix. If there are more problems lurking then we > only have one more build in which to find and fix them. > > So at the moment I'm leaning against these. Comments? > > - Mark From Kelly.Ohair at Sun.COM Thu May 7 12:40:52 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 07 May 2009 12:40:52 -0700 Subject: M3 stabilization requests for 2009/5/7 (b58) [part 2] In-Reply-To: <20090507192518.F35A85E96@eggemoggin.niobe.net> References: <20090507192518.F35A85E96@eggemoggin.niobe.net> Message-ID: <4A033944.60409@sun.com> As a point of information... From the beginning these changes have been in the build forest and have been building fine with JPRT via Windows CGYWIN shell started make commands. The problems we had centered around Windows builds in some environments (e.g. Xiomara's RE windows machines) where ant.bat happened to be used. The changes also only impact debug builds not the product builds. But the changes are also not critical fixes, so whatever you decide is ok with me. -kto Mark Reinhold wrote: > These just came in, and Xiomara would like to get them into b58. > > 6829575 kelly.ohair 100028: Debug information is incomplete or > missing > > 6832141 kelly.ohair Bug 100045 - Fix for 100028 breaks debug info for > class files > > 6837665 kelly.ohair Deal with windows ant problem where commas in -D > options do not work > > These are all worthwhile fixes, but I'm a bit nervous about changing > makefiles so late in the game. The second two bugs above are fixes to > the first -- which is no criticism of either Andrew or Kelly, it's just > a consequence of the complexity of our build system and the size of the > supported-platform matrix. If there are more problems lurking then we > only have one more build in which to find and fix them. > > So at the moment I'm leaning against these. Comments? > > - Mark From Paul.Hohensee at Sun.COM Thu May 7 12:46:10 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Thu, 07 May 2009 15:46:10 -0400 Subject: Hotspot bug approval request Message-ID: <4A033A82.1060601@sun.com> 6490395: G1: Tidy up command line flags Another g1-only change. Paul From mr at sun.com Thu May 7 22:01:43 2009 From: mr at sun.com (Mark Reinhold) Date: Thu, 07 May 2009 22:01:43 -0700 Subject: Build and Integration schedule -- skip weeks In-Reply-To: xiomara.jayasena@sun.com; Wed, 06 May 2009 13:01:40 PDT; <4A01ECA4.8030608@Sun.COM> Message-ID: <20090508050143.1F942913F@callebaut.niobe.net> > Date: Wed, 06 May 2009 13:01:40 -0700 > From: xiomara.jayasena at sun.com > Should I have integration slots for the weeks that we will "skip"? I > think it is OK to allow gatekeepers to integrate during that time right? > except that we would not do promotions during that time frame. > > b59 2009/05/14 ---- b59 ---- * > b60 2009/05/15 > > b60 2009/05/18 JAXB-WS I18N > b60 2009/05/19 2D Deploy/Hotspot > b60 2009/05/20 Build > b60 2009/05/21 ---- b60 ---- * > b61 2009/05/22 TL/JSN > > b61 2009/05/25 L10N JAXP > b61 2009/05/26 EE AWT/Hotspot > b61 2009/05/27 Swing Build > b61 2009/05/28 > b61 2009/05/29 > > b61 2009/06/01 JAXB-WS I18N > b61 2009/06/02 2D Deploy/Hotspot > b61 2009/06/03 Build > b61 2009/06/04 > b61 2009/06/05 TL/JSN > > b61 2009/06/08 L10N JAXP > b61 2009/06/09 EE AWT/Hotspot > b61 2009/06/10 Swing Build > b61 2009/06/11 ---- b61 ---- * > b62 2009/06/12 > > > Please let me know and I will update the build and integration schedule. Yes. In fact I think we should allow integrations into the master for M4 to start the day after b59 is promoted, and they should continue as usual through the skipped weeks. If we need to use b60 for M3 then we'll spin up a special forest just for that purpose. Release Team: Comments? - Mark From mr at sun.com Fri May 8 09:01:29 2009 From: mr at sun.com (Mark Reinhold) Date: Fri, 08 May 2009 09:01:29 -0700 Subject: Build and Integration schedule -- skip weeks In-Reply-To: xiomara.jayasena@sun.com; Fri, 08 May 2009 08:20:13 PDT; <4A044DAD.8090208@sun.com> Message-ID: <20090508160129.E6ACD5E2F@eggemoggin.niobe.net> > Date: Fri, 08 May 2009 08:20:13 -0700 > From: xiomara.jayasena at sun.com > I was under the impression that b60 was going to be the last build for > M3 and according to the Calendar here: > http://openjdk.java.net/projects/jdk7/calendar/ > it shows that b60 is the last build for M3. Are we saying that b59 is > now going to be the last build in M3 then? Build 60 is the last scheduled build for M3. It's the showstopper build. If we need it, we'll do it; if we don't, then we'll skip it. I suggest you leave 60 in the schedule until we make that decision. If we skip 60 then that does raise the question of whether what's now called 61 should be renamed to 60, and so forth for all following builds. Personally I'd prefer to keep the present numbering and just document the fact that we skipped 60. I tend to view build numbers as part of the calendar. If you don't do something on a particular day then that doesn't mean you remove the day from the calendar, it just means that you do it on some later day. What do others think? - Mark From Paul.Hohensee at Sun.COM Fri May 8 09:08:06 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Fri, 08 May 2009 12:08:06 -0400 Subject: Build and Integration schedule -- skip weeks In-Reply-To: <20090508160129.E6ACD5E2F@eggemoggin.niobe.net> References: <20090508160129.E6ACD5E2F@eggemoggin.niobe.net> Message-ID: <4A0458E6.4030604@sun.com> Skip build 60 as you recommend. paul Mark Reinhold wrote: >> Date: Fri, 08 May 2009 08:20:13 -0700 >> From: xiomara.jayasena at sun.com >> > > >> I was under the impression that b60 was going to be the last build for >> M3 and according to the Calendar here: >> http://openjdk.java.net/projects/jdk7/calendar/ >> it shows that b60 is the last build for M3. Are we saying that b59 is >> now going to be the last build in M3 then? >> > > Build 60 is the last scheduled build for M3. It's the showstopper build. > If we need it, we'll do it; if we don't, then we'll skip it. I suggest > you leave 60 in the schedule until we make that decision. > > If we skip 60 then that does raise the question of whether what's now > called 61 should be renamed to 60, and so forth for all following builds. > Personally I'd prefer to keep the present numbering and just document the > fact that we skipped 60. I tend to view build numbers as part of the > calendar. If you don't do something on a particular day then that > doesn't mean you remove the day from the calendar, it just means that > you do it on some later day. > > What do others think? > > - Mark > From Joe.Darcy at Sun.COM Fri May 8 09:15:49 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 08 May 2009 09:15:49 -0700 Subject: Build and Integration schedule -- skip weeks In-Reply-To: <20090508160129.E6ACD5E2F@eggemoggin.niobe.net> References: <20090508160129.E6ACD5E2F@eggemoggin.niobe.net> Message-ID: <4A045AB5.3030000@sun.com> Mark Reinhold wrote: >> Date: Fri, 08 May 2009 08:20:13 -0700 >> From: xiomara.jayasena at sun.com >> > > >> I was under the impression that b60 was going to be the last build for >> M3 and according to the Calendar here: >> http://openjdk.java.net/projects/jdk7/calendar/ >> it shows that b60 is the last build for M3. Are we saying that b59 is >> now going to be the last build in M3 then? >> > > Build 60 is the last scheduled build for M3. It's the showstopper build. > If we need it, we'll do it; if we don't, then we'll skip it. I suggest > you leave 60 in the schedule until we make that decision. > > If we skip 60 then that does raise the question of whether what's now > called 61 should be renamed to 60, and so forth for all following builds. > Personally I'd prefer to keep the present numbering and just document the > fact that we skipped 60. I tend to view build numbers as part of the > calendar. If you don't do something on a particular day then that > doesn't mean you remove the day from the calendar, it just means that > you do it on some later day. > > What do others think? > > > I'd prefer to renumber b61 to b60 is b60 is skipped. I think it is less confusing long term to have the build numbers be a dense consective sequence of integers. -Joe From Paul.Hohensee at Sun.COM Fri May 8 09:21:46 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Fri, 08 May 2009 12:21:46 -0400 Subject: Build and Integration schedule -- skip weeks In-Reply-To: <4A045AB5.3030000@sun.com> References: <20090508160129.E6ACD5E2F@eggemoggin.niobe.net> <4A045AB5.3030000@sun.com> Message-ID: <4A045C1A.3030400@sun.com> Could also just build b60 to be identical to b59. I.e., the only difference between b59 and b60 bundles would be the build number. Paul Joseph D. Darcy wrote: > Mark Reinhold wrote: >>> Date: Fri, 08 May 2009 08:20:13 -0700 >>> From: xiomara.jayasena at sun.com >>> >> >> >>> I was under the impression that b60 was going to be the last build for >>> M3 and according to the Calendar here: >>> http://openjdk.java.net/projects/jdk7/calendar/ >>> it shows that b60 is the last build for M3. Are we saying that b59 is >>> now going to be the last build in M3 then? >>> >> >> Build 60 is the last scheduled build for M3. It's the showstopper >> build. >> If we need it, we'll do it; if we don't, then we'll skip it. I suggest >> you leave 60 in the schedule until we make that decision. >> >> If we skip 60 then that does raise the question of whether what's now >> called 61 should be renamed to 60, and so forth for all following >> builds. >> Personally I'd prefer to keep the present numbering and just document >> the >> fact that we skipped 60. I tend to view build numbers as part of the >> calendar. If you don't do something on a particular day then that >> doesn't mean you remove the day from the calendar, it just means that >> you do it on some later day. >> >> What do others think? >> >> >> > > I'd prefer to renumber b61 to b60 is b60 is skipped. > > I think it is less confusing long term to have the build numbers be a > dense consective sequence of integers. > > -Joe > From Joe.Darcy at Sun.COM Fri May 8 09:33:13 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 08 May 2009 09:33:13 -0700 Subject: Build and Integration schedule -- skip weeks In-Reply-To: <4A045C1A.3030400@sun.com> References: <20090508160129.E6ACD5E2F@eggemoggin.niobe.net> <4A045AB5.3030000@sun.com> <4A045C1A.3030400@sun.com> Message-ID: <4A045EC9.9010802@sun.com> Paul Hohensee wrote: > Could also just build b60 to be identical to b59. I.e., the only > difference > between b59 and b60 bundles would be the build number. That would be preferable to skipping a build number. -Joe > > Paul > > Joseph D. Darcy wrote: >> Mark Reinhold wrote: >>>> Date: Fri, 08 May 2009 08:20:13 -0700 >>>> From: xiomara.jayasena at sun.com >>>> >>> >>> >>>> I was under the impression that b60 was going to be the last build for >>>> M3 and according to the Calendar here: >>>> http://openjdk.java.net/projects/jdk7/calendar/ >>>> it shows that b60 is the last build for M3. Are we saying that b59 is >>>> now going to be the last build in M3 then? >>>> >>> >>> Build 60 is the last scheduled build for M3. It's the showstopper >>> build. >>> If we need it, we'll do it; if we don't, then we'll skip it. I suggest >>> you leave 60 in the schedule until we make that decision. >>> >>> If we skip 60 then that does raise the question of whether what's now >>> called 61 should be renamed to 60, and so forth for all following >>> builds. >>> Personally I'd prefer to keep the present numbering and just >>> document the >>> fact that we skipped 60. I tend to view build numbers as part of the >>> calendar. If you don't do something on a particular day then that >>> doesn't mean you remove the day from the calendar, it just means that >>> you do it on some later day. >>> >>> What do others think? >>> >>> >>> >> >> I'd prefer to renumber b61 to b60 is b60 is skipped. >> >> I think it is less confusing long term to have the build numbers be a >> dense consective sequence of integers. >> >> -Joe >> From Xiomara.Jayasena at Sun.COM Fri May 8 10:07:04 2009 From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena) Date: Fri, 08 May 2009 10:07:04 -0700 Subject: Build and Integration schedule -- skip weeks In-Reply-To: <4A045C1A.3030400@sun.com> References: <20090508160129.E6ACD5E2F@eggemoggin.niobe.net> <4A045AB5.3030000@sun.com> <4A045C1A.3030400@sun.com> Message-ID: <4A0466B8.6000406@sun.com> There is no really point in doing a promotion if nothing has changed. Would a link for the skipped build to the previous build number suffice, instead? -Xiomara Paul Hohensee wrote: > Could also just build b60 to be identical to b59. I.e., the only > difference > between b59 and b60 bundles would be the build number. > > Paul > > Joseph D. Darcy wrote: >> Mark Reinhold wrote: >>>> Date: Fri, 08 May 2009 08:20:13 -0700 >>>> From: xiomara.jayasena at sun.com >>>> >>> >>> >>>> I was under the impression that b60 was going to be the last build for >>>> M3 and according to the Calendar here: >>>> http://openjdk.java.net/projects/jdk7/calendar/ >>>> it shows that b60 is the last build for M3. Are we saying that b59 is >>>> now going to be the last build in M3 then? >>>> >>> >>> Build 60 is the last scheduled build for M3. It's the showstopper >>> build. >>> If we need it, we'll do it; if we don't, then we'll skip it. I suggest >>> you leave 60 in the schedule until we make that decision. >>> >>> If we skip 60 then that does raise the question of whether what's now >>> called 61 should be renamed to 60, and so forth for all following >>> builds. >>> Personally I'd prefer to keep the present numbering and just >>> document the >>> fact that we skipped 60. I tend to view build numbers as part of the >>> calendar. If you don't do something on a particular day then that >>> doesn't mean you remove the day from the calendar, it just means that >>> you do it on some later day. >>> >>> What do others think? >>> >>> >>> >> >> I'd prefer to renumber b61 to b60 is b60 is skipped. >> >> I think it is less confusing long term to have the build numbers be a >> dense consective sequence of integers. >> >> -Joe >> From Joe.Darcy at Sun.COM Fri May 8 10:06:33 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 08 May 2009 10:06:33 -0700 Subject: Build and Integration schedule -- skip weeks In-Reply-To: <4A0466B8.6000406@sun.com> References: <20090508160129.E6ACD5E2F@eggemoggin.niobe.net> <4A045AB5.3030000@sun.com> <4A045C1A.3030400@sun.com> <4A0466B8.6000406@sun.com> Message-ID: <4A046699.2020601@sun.com> Xiomara Jayasena wrote: > > There is no really point in doing a promotion if nothing has changed. > Would a link for the skipped build to the previous build number > suffice, instead? The appropriate state of the source code in the repositories should also be tagged for both builds in this situation. Basically, places where people get the build from, source, binaries, etc., should have a conceptual link from the skipped build to the prior one. -Joe > > -Xiomara > > > Paul Hohensee wrote: >> Could also just build b60 to be identical to b59. I.e., the only >> difference >> between b59 and b60 bundles would be the build number. >> >> Paul >> >> Joseph D. Darcy wrote: >>> Mark Reinhold wrote: >>>>> Date: Fri, 08 May 2009 08:20:13 -0700 >>>>> From: xiomara.jayasena at sun.com >>>>> >>>> >>>> >>>>> I was under the impression that b60 was going to be the last build >>>>> for >>>>> M3 and according to the Calendar here: >>>>> http://openjdk.java.net/projects/jdk7/calendar/ >>>>> it shows that b60 is the last build for M3. Are we saying that >>>>> b59 is >>>>> now going to be the last build in M3 then? >>>>> >>>> >>>> Build 60 is the last scheduled build for M3. It's the showstopper >>>> build. >>>> If we need it, we'll do it; if we don't, then we'll skip it. I >>>> suggest >>>> you leave 60 in the schedule until we make that decision. >>>> >>>> If we skip 60 then that does raise the question of whether what's now >>>> called 61 should be renamed to 60, and so forth for all following >>>> builds. >>>> Personally I'd prefer to keep the present numbering and just >>>> document the >>>> fact that we skipped 60. I tend to view build numbers as part of the >>>> calendar. If you don't do something on a particular day then that >>>> doesn't mean you remove the day from the calendar, it just means that >>>> you do it on some later day. >>>> >>>> What do others think? >>>> >>>> >>>> >>> >>> I'd prefer to renumber b61 to b60 is b60 is skipped. >>> >>> I think it is less confusing long term to have the build numbers be >>> a dense consective sequence of integers. >>> >>> -Joe >>> From Paul.Hohensee at Sun.COM Fri May 8 10:07:58 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Fri, 08 May 2009 13:07:58 -0400 Subject: Build and Integration schedule -- skip weeks In-Reply-To: <4A0466B8.6000406@sun.com> References: <20090508160129.E6ACD5E2F@eggemoggin.niobe.net> <4A045AB5.3030000@sun.com> <4A045C1A.3030400@sun.com> <4A0466B8.6000406@sun.com> Message-ID: <4A0466EE.2050903@sun.com> We'd need the bundle names to be "b60" and "java -version" to return "b60". Paul Xiomara Jayasena wrote: > > There is no really point in doing a promotion if nothing has changed. > Would a link for the skipped build to the previous build number > suffice, instead? > > -Xiomara > > > Paul Hohensee wrote: >> Could also just build b60 to be identical to b59. I.e., the only >> difference >> between b59 and b60 bundles would be the build number. >> >> Paul >> >> Joseph D. Darcy wrote: >>> Mark Reinhold wrote: >>>>> Date: Fri, 08 May 2009 08:20:13 -0700 >>>>> From: xiomara.jayasena at sun.com >>>>> >>>> >>>> >>>>> I was under the impression that b60 was going to be the last build >>>>> for >>>>> M3 and according to the Calendar here: >>>>> http://openjdk.java.net/projects/jdk7/calendar/ >>>>> it shows that b60 is the last build for M3. Are we saying that >>>>> b59 is >>>>> now going to be the last build in M3 then? >>>>> >>>> >>>> Build 60 is the last scheduled build for M3. It's the showstopper >>>> build. >>>> If we need it, we'll do it; if we don't, then we'll skip it. I >>>> suggest >>>> you leave 60 in the schedule until we make that decision. >>>> >>>> If we skip 60 then that does raise the question of whether what's now >>>> called 61 should be renamed to 60, and so forth for all following >>>> builds. >>>> Personally I'd prefer to keep the present numbering and just >>>> document the >>>> fact that we skipped 60. I tend to view build numbers as part of the >>>> calendar. If you don't do something on a particular day then that >>>> doesn't mean you remove the day from the calendar, it just means that >>>> you do it on some later day. >>>> >>>> What do others think? >>>> >>>> >>>> >>> >>> I'd prefer to renumber b61 to b60 is b60 is skipped. >>> >>> I think it is less confusing long term to have the build numbers be >>> a dense consective sequence of integers. >>> >>> -Joe >>> From mr at sun.com Fri May 8 11:56:02 2009 From: mr at sun.com (Mark Reinhold) Date: Fri, 08 May 2009 11:56:02 -0700 Subject: M3 stabilization requests for 2009/5/7 (b58) [part 2] In-Reply-To: mr@sun.com; Thu, 07 May 2009 12:25:18 PDT; <20090507192518.F35A85E96@eggemoggin.niobe.net> Message-ID: <20090508185602.59BF95E2F@eggemoggin.niobe.net> Okay, I'll mark these three "m3-no". - Mark From Paul.Hohensee at Sun.COM Fri May 8 13:20:51 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Fri, 08 May 2009 16:20:51 -0400 Subject: one last hotspot approval request for b59 Message-ID: <4A049423.2030807@sun.com> 6838842 NUMA allocator: Segfault during startup on Linux One line fix to make UseNUMA work on Linux again. Thanks, Paul From Xiomara.Jayasena at Sun.COM Fri May 8 14:12:20 2009 From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena) Date: Fri, 08 May 2009 14:12:20 -0700 Subject: Build and Integration schedule -- skip weeks In-Reply-To: <4A046699.2020601@sun.com> References: <20090508160129.E6ACD5E2F@eggemoggin.niobe.net> <4A045AB5.3030000@sun.com> <4A045C1A.3030400@sun.com> <4A0466B8.6000406@sun.com> <4A046699.2020601@sun.com> Message-ID: <4A04A034.80501@sun.com> Joseph D. Darcy wrote: > Xiomara Jayasena wrote: >> >> There is no really point in doing a promotion if nothing has >> changed. Would a link for the skipped build to the previous build >> number suffice, instead? > > The appropriate state of the source code in the repositories should > also be tagged for both builds in this situation. > > Basically, places where people get the build from, source, binaries, > etc., should have a conceptual link from the skipped build to the > prior one. In the long term the above could become quite confusing. I do not quite understand the need to skip build numbers or re-build. I believe in the past RE has done neither, we just update whatever documents need to be updated. I can see that publishing a calendar in advance and knowing what build number to target for, is very useful for gatekeepers, so if we must do one of the two options above then skipping numbers maybe the best alternative, from RE's perspective. -Xiomara > > -Joe > >> >> -Xiomara >> >> >> Paul Hohensee wrote: >>> Could also just build b60 to be identical to b59. I.e., the only >>> difference >>> between b59 and b60 bundles would be the build number. >>> >>> Paul >>> >>> Joseph D. Darcy wrote: >>>> Mark Reinhold wrote: >>>>>> Date: Fri, 08 May 2009 08:20:13 -0700 >>>>>> From: xiomara.jayasena at sun.com >>>>>> >>>>> >>>>> >>>>>> I was under the impression that b60 was going to be the last >>>>>> build for >>>>>> M3 and according to the Calendar here: >>>>>> http://openjdk.java.net/projects/jdk7/calendar/ >>>>>> it shows that b60 is the last build for M3. Are we saying that >>>>>> b59 is >>>>>> now going to be the last build in M3 then? >>>>>> >>>>> >>>>> Build 60 is the last scheduled build for M3. It's the showstopper >>>>> build. >>>>> If we need it, we'll do it; if we don't, then we'll skip it. I >>>>> suggest >>>>> you leave 60 in the schedule until we make that decision. >>>>> >>>>> If we skip 60 then that does raise the question of whether what's now >>>>> called 61 should be renamed to 60, and so forth for all following >>>>> builds. >>>>> Personally I'd prefer to keep the present numbering and just >>>>> document the >>>>> fact that we skipped 60. I tend to view build numbers as part of the >>>>> calendar. If you don't do something on a particular day then that >>>>> doesn't mean you remove the day from the calendar, it just means that >>>>> you do it on some later day. >>>>> >>>>> What do others think? >>>>> >>>>> >>>>> >>>> >>>> I'd prefer to renumber b61 to b60 is b60 is skipped. >>>> >>>> I think it is less confusing long term to have the build numbers be >>>> a dense consective sequence of integers. >>>> >>>> -Joe >>>> > From mr at sun.com Fri May 8 14:10:23 2009 From: mr at sun.com (Mark Reinhold) Date: Fri, 08 May 2009 14:10:23 -0700 Subject: one last hotspot approval request for b59 In-Reply-To: paul.hohensee@sun.com; Fri, 08 May 2009 16:20:51 EDT; <4A049423.2030807@sun.com> Message-ID: <20090508211023.6D6DD5E2F@eggemoggin.niobe.net> > Date: Fri, 08 May 2009 16:20:51 -0400 > From: paul.hohensee at sun.com > 6838842 NUMA allocator: Segfault during startup on Linux > > One line fix to make UseNUMA work on Linux again. Has this fix soaked in an earlier release yet? If not, what testing has been done? How critical is it that UseNUMA work on Linux? It looks innocuous enough, but I'm paranoid. - Mark From Joe.Darcy at Sun.COM Fri May 8 14:16:05 2009 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Fri, 08 May 2009 14:16:05 -0700 Subject: Build and Integration schedule -- skip weeks In-Reply-To: <4A04A034.80501@sun.com> References: <20090508160129.E6ACD5E2F@eggemoggin.niobe.net> <4A045AB5.3030000@sun.com> <4A045C1A.3030400@sun.com> <4A0466B8.6000406@sun.com> <4A046699.2020601@sun.com> <4A04A034.80501@sun.com> Message-ID: <4A04A115.2080301@sun.com> On 05/08/09 02:12 PM, Xiomara Jayasena wrote: > > > Joseph D. Darcy wrote: >> Xiomara Jayasena wrote: >>> >>> There is no really point in doing a promotion if nothing has >>> changed. Would a link for the skipped build to the previous build >>> number suffice, instead? >> >> The appropriate state of the source code in the repositories should >> also be tagged for both builds in this situation. >> >> Basically, places where people get the build from, source, binaries, >> etc., should have a conceptual link from the skipped build to the >> prior one. > > In the long term the above could become quite confusing. > I do not quite understand the need to skip build numbers or re-build. > I believe in the past RE has done neither, we just update whatever > documents need to be updated. > > I can see that publishing a calendar in advance and knowing what build > number to target for, is very useful for gatekeepers, so if we must do > one of the two options above then skipping numbers maybe the best > alternative, from RE's perspective. I find skipped build numbers to have a very high long-term cognitive cost. Nine months, or a year or two years after JDK7 m3 when someone is trying to track down in which build a bug was introduced, how likely is it that he or she will remember, "Ah yes, b60 was skipped because that was the stopper build for JDK 7 m3 and there were no problems to fix!" Missing build numbers create questions rather than answers and complicate attempts to perform things like binary search on the builds. I think the set of build numbers should be a dense sequence of consecutive integers. There are multiple ways of achieving this and I don't have a strong preference between: * Rename b61 as b60 if m03 doesn't need a stopped build * Make b60 a duplicate of b59 if no stopper fixes are needed -Joe > > -Xiomara > >> >> -Joe >> >>> >>> -Xiomara >>> >>> >>> Paul Hohensee wrote: >>>> Could also just build b60 to be identical to b59. I.e., the only >>>> difference >>>> between b59 and b60 bundles would be the build number. >>>> >>>> Paul >>>> >>>> Joseph D. Darcy wrote: >>>>> Mark Reinhold wrote: >>>>>>> Date: Fri, 08 May 2009 08:20:13 -0700 >>>>>>> From: xiomara.jayasena at sun.com >>>>>>> >>>>>> >>>>>> >>>>>>> I was under the impression that b60 was going to be the last >>>>>>> build for >>>>>>> M3 and according to the Calendar here: >>>>>>> http://openjdk.java.net/projects/jdk7/calendar/ >>>>>>> it shows that b60 is the last build for M3. Are we saying that >>>>>>> b59 is >>>>>>> now going to be the last build in M3 then? >>>>>>> >>>>>> >>>>>> Build 60 is the last scheduled build for M3. It's the >>>>>> showstopper build. >>>>>> If we need it, we'll do it; if we don't, then we'll skip it. I >>>>>> suggest >>>>>> you leave 60 in the schedule until we make that decision. >>>>>> >>>>>> If we skip 60 then that does raise the question of whether what's >>>>>> now >>>>>> called 61 should be renamed to 60, and so forth for all following >>>>>> builds. >>>>>> Personally I'd prefer to keep the present numbering and just >>>>>> document the >>>>>> fact that we skipped 60. I tend to view build numbers as part of >>>>>> the >>>>>> calendar. If you don't do something on a particular day then that >>>>>> doesn't mean you remove the day from the calendar, it just means >>>>>> that >>>>>> you do it on some later day. >>>>>> >>>>>> What do others think? >>>>>> >>>>>> >>>>>> >>>>> >>>>> I'd prefer to renumber b61 to b60 is b60 is skipped. >>>>> >>>>> I think it is less confusing long term to have the build numbers >>>>> be a dense consective sequence of integers. >>>>> >>>>> -Joe >>>>> >> From Xiomara.Jayasena at Sun.COM Fri May 8 14:29:32 2009 From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena) Date: Fri, 08 May 2009 14:29:32 -0700 Subject: Build and Integration schedule -- skip weeks In-Reply-To: <4A04A115.2080301@sun.com> References: <20090508160129.E6ACD5E2F@eggemoggin.niobe.net> <4A045AB5.3030000@sun.com> <4A045C1A.3030400@sun.com> <4A0466B8.6000406@sun.com> <4A046699.2020601@sun.com> <4A04A034.80501@sun.com> <4A04A115.2080301@sun.com> Message-ID: <4A04A43C.2020400@sun.com> Joe Darcy wrote: > On 05/08/09 02:12 PM, Xiomara Jayasena wrote: >> >> >> Joseph D. Darcy wrote: >>> Xiomara Jayasena wrote: >>>> >>>> There is no really point in doing a promotion if nothing has >>>> changed. Would a link for the skipped build to the previous build >>>> number suffice, instead? >>> >>> The appropriate state of the source code in the repositories should >>> also be tagged for both builds in this situation. >>> >>> Basically, places where people get the build from, source, binaries, >>> etc., should have a conceptual link from the skipped build to the >>> prior one. >> >> In the long term the above could become quite confusing. >> I do not quite understand the need to skip build numbers or >> re-build. I believe in the past RE has done neither, we just update >> whatever documents need to be updated. >> >> I can see that publishing a calendar in advance and knowing what >> build number to target for, is very useful for gatekeepers, so if we >> must do one of the two options above then skipping numbers maybe the >> best alternative, from RE's perspective. > > I find skipped build numbers to have a very high long-term cognitive > cost. Nine months, or a year or two years after JDK7 m3 when someone > is trying to track down in which build a bug was introduced, how > likely is it that he or she will remember, "Ah yes, b60 was skipped > because that was the stopper build for JDK 7 m3 and there were no > problems to fix!" Missing build numbers create questions rather than > answers and complicate attempts to perform things like binary search > on the builds. > > I think the set of build numbers should be a dense sequence of > consecutive integers. There are multiple ways of achieving this and I > don't have a strong preference between: > > * Rename b61 as b60 if m03 doesn't need a stopped build Renaming in RE terms translates to re-building. > * Make b60 a duplicate of b59 if no stopper fixes are needed Again, that pretty much means rebuilding, to have bundle names, etc. include the new build number. -Xiomara > > -Joe > >> >> -Xiomara >> >>> >>> -Joe >>> >>>> >>>> -Xiomara >>>> >>>> >>>> Paul Hohensee wrote: >>>>> Could also just build b60 to be identical to b59. I.e., the only >>>>> difference >>>>> between b59 and b60 bundles would be the build number. >>>>> >>>>> Paul >>>>> >>>>> Joseph D. Darcy wrote: >>>>>> Mark Reinhold wrote: >>>>>>>> Date: Fri, 08 May 2009 08:20:13 -0700 >>>>>>>> From: xiomara.jayasena at sun.com >>>>>>>> >>>>>>> >>>>>>> >>>>>>>> I was under the impression that b60 was going to be the last >>>>>>>> build for >>>>>>>> M3 and according to the Calendar here: >>>>>>>> http://openjdk.java.net/projects/jdk7/calendar/ >>>>>>>> it shows that b60 is the last build for M3. Are we saying that >>>>>>>> b59 is >>>>>>>> now going to be the last build in M3 then? >>>>>>>> >>>>>>> >>>>>>> Build 60 is the last scheduled build for M3. It's the >>>>>>> showstopper build. >>>>>>> If we need it, we'll do it; if we don't, then we'll skip it. I >>>>>>> suggest >>>>>>> you leave 60 in the schedule until we make that decision. >>>>>>> >>>>>>> If we skip 60 then that does raise the question of whether >>>>>>> what's now >>>>>>> called 61 should be renamed to 60, and so forth for all >>>>>>> following builds. >>>>>>> Personally I'd prefer to keep the present numbering and just >>>>>>> document the >>>>>>> fact that we skipped 60. I tend to view build numbers as part >>>>>>> of the >>>>>>> calendar. If you don't do something on a particular day then that >>>>>>> doesn't mean you remove the day from the calendar, it just means >>>>>>> that >>>>>>> you do it on some later day. >>>>>>> >>>>>>> What do others think? >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> I'd prefer to renumber b61 to b60 is b60 is skipped. >>>>>> >>>>>> I think it is less confusing long term to have the build numbers >>>>>> be a dense consective sequence of integers. >>>>>> >>>>>> -Joe >>>>>> >>> > From Paul.Hohensee at Sun.COM Fri May 8 14:26:52 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Fri, 08 May 2009 17:26:52 -0400 Subject: one last hotspot approval request for b59 In-Reply-To: <20090508211023.6D6DD5E2F@eggemoggin.niobe.net> References: <20090508211023.6D6DD5E2F@eggemoggin.niobe.net> Message-ID: <4A04A39C.3020900@sun.com> Yes. It restores the behavior previous to this changeset http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/6bdd6923ba16 so it's been thoroughly tested. UseNUMA is used for both specjbb2005 single jvm runs and specjvm2008 runs, so it's fairly critical. Also, free_memory() is only used by the NUMA collector. We're going to push it into hs15 for 6u14p, for which it's the last minute as well. I can understand the paranoia. Paul Mark Reinhold wrote: >> Date: Fri, 08 May 2009 16:20:51 -0400 >> From: paul.hohensee at sun.com >> > > >> 6838842 NUMA allocator: Segfault during startup on Linux >> >> One line fix to make UseNUMA work on Linux again. >> > > Has this fix soaked in an earlier release yet? > > If not, what testing has been done? > > How critical is it that UseNUMA work on Linux? > > It looks innocuous enough, but I'm paranoid. > > - Mark > From Joe.Darcy at Sun.COM Fri May 8 14:47:35 2009 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Fri, 08 May 2009 14:47:35 -0700 Subject: Build and Integration schedule -- skip weeks In-Reply-To: <4A04A43C.2020400@sun.com> References: <20090508160129.E6ACD5E2F@eggemoggin.niobe.net> <4A045AB5.3030000@sun.com> <4A045C1A.3030400@sun.com> <4A0466B8.6000406@sun.com> <4A046699.2020601@sun.com> <4A04A034.80501@sun.com> <4A04A115.2080301@sun.com> <4A04A43C.2020400@sun.com> Message-ID: <4A04A877.4060401@sun.com> On 05/08/09 02:29 PM, Xiomara Jayasena wrote: > > > Joe Darcy wrote: >> On 05/08/09 02:12 PM, Xiomara Jayasena wrote: >>> >>> >>> Joseph D. Darcy wrote: >>>> Xiomara Jayasena wrote: >>>>> >>>>> There is no really point in doing a promotion if nothing has >>>>> changed. Would a link for the skipped build to the previous build >>>>> number suffice, instead? >>>> >>>> The appropriate state of the source code in the repositories should >>>> also be tagged for both builds in this situation. >>>> >>>> Basically, places where people get the build from, source, >>>> binaries, etc., should have a conceptual link from the skipped >>>> build to the prior one. >>> >>> In the long term the above could become quite confusing. >>> I do not quite understand the need to skip build numbers or >>> re-build. I believe in the past RE has done neither, we just update >>> whatever documents need to be updated. >>> >>> I can see that publishing a calendar in advance and knowing what >>> build number to target for, is very useful for gatekeepers, so if we >>> must do one of the two options above then skipping numbers maybe the >>> best alternative, from RE's perspective. >> >> I find skipped build numbers to have a very high long-term cognitive >> cost. Nine months, or a year or two years after JDK7 m3 when someone >> is trying to track down in which build a bug was introduced, how >> likely is it that he or she will remember, "Ah yes, b60 was skipped >> because that was the stopper build for JDK 7 m3 and there were no >> problems to fix!" Missing build numbers create questions rather than >> answers and complicate attempts to perform things like binary search >> on the builds. >> >> I think the set of build numbers should be a dense sequence of >> consecutive integers. There are multiple ways of achieving this and >> I don't have a strong preference between: >> >> * Rename b61 as b60 if m03 doesn't need a stopped build > > Renaming in RE terms translates to re-building. By renaming in this context, I mean to update the schedule documents so that the first build of m04 would be called "b60" rather than "b61." -Joe From Xiomara.Jayasena at Sun.COM Fri May 8 15:01:14 2009 From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena) Date: Fri, 08 May 2009 15:01:14 -0700 Subject: Build and Integration schedule -- skip weeks In-Reply-To: <4A04A877.4060401@sun.com> References: <20090508160129.E6ACD5E2F@eggemoggin.niobe.net> <4A045AB5.3030000@sun.com> <4A045C1A.3030400@sun.com> <4A0466B8.6000406@sun.com> <4A046699.2020601@sun.com> <4A04A034.80501@sun.com> <4A04A115.2080301@sun.com> <4A04A43C.2020400@sun.com> <4A04A877.4060401@sun.com> Message-ID: <4A04ABAA.7090600@sun.com> Joe Darcy wrote: > On 05/08/09 02:29 PM, Xiomara Jayasena wrote: >> >> >> Joe Darcy wrote: >>> On 05/08/09 02:12 PM, Xiomara Jayasena wrote: >>>> >>>> >>>> Joseph D. Darcy wrote: >>>>> Xiomara Jayasena wrote: >>>>>> >>>>>> There is no really point in doing a promotion if nothing has >>>>>> changed. Would a link for the skipped build to the previous >>>>>> build number suffice, instead? >>>>> >>>>> The appropriate state of the source code in the repositories >>>>> should also be tagged for both builds in this situation. >>>>> >>>>> Basically, places where people get the build from, source, >>>>> binaries, etc., should have a conceptual link from the skipped >>>>> build to the prior one. >>>> >>>> In the long term the above could become quite confusing. >>>> I do not quite understand the need to skip build numbers or >>>> re-build. I believe in the past RE has done neither, we just >>>> update whatever documents need to be updated. >>>> >>>> I can see that publishing a calendar in advance and knowing what >>>> build number to target for, is very useful for gatekeepers, so if >>>> we must do one of the two options above then skipping numbers maybe >>>> the best alternative, from RE's perspective. >>> >>> I find skipped build numbers to have a very high long-term cognitive >>> cost. Nine months, or a year or two years after JDK7 m3 when >>> someone is trying to track down in which build a bug was introduced, >>> how likely is it that he or she will remember, "Ah yes, b60 was >>> skipped because that was the stopper build for JDK 7 m3 and there >>> were no problems to fix!" Missing build numbers create questions >>> rather than answers and complicate attempts to perform things like >>> binary search on the builds. >>> >>> I think the set of build numbers should be a dense sequence of >>> consecutive integers. There are multiple ways of achieving this and >>> I don't have a strong preference between: >>> >>> * Rename b61 as b60 if m03 doesn't need a stopped build >> >> Renaming in RE terms translates to re-building. > > By renaming in this context, I mean to update the schedule documents > so that the first build of m04 would be called "b60" rather than "b61." This would seem like the best approach to me as well. -Xiomara > > -Joe > From mr at sun.com Fri May 8 15:06:10 2009 From: mr at sun.com (Mark Reinhold) Date: Fri, 08 May 2009 15:06:10 -0700 Subject: one last hotspot approval request for b59 In-Reply-To: paul.hohensee@sun.com; Fri, 08 May 2009 17:26:52 EDT; <4A04A39C.3020900@sun.com> Message-ID: <20090508220610.5C61C5E2F@eggemoggin.niobe.net> > Date: Fri, 08 May 2009 17:26:52 -0400 > From: paul.hohensee at sun.com > Yes. It restores the behavior previous to this changeset > > http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/6bdd6923ba16 > > so it's been thoroughly tested. > > UseNUMA is used for both specjbb2005 single jvm runs and specjvm2008 runs, > so it's fairly critical. Also, free_memory() is only used by the NUMA > collector. > We're going to push it into hs15 for 6u14p, for which it's the last > minute as well. Okay, thanks for the explanation. I'll approve this one. - Mark From Paul.Hohensee at Sun.COM Fri May 8 15:38:19 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Fri, 08 May 2009 18:38:19 -0400 Subject: one last hotspot approval request for b59 In-Reply-To: <20090508220610.5C61C5E2F@eggemoggin.niobe.net> References: <20090508220610.5C61C5E2F@eggemoggin.niobe.net> Message-ID: <4A04B45B.8070702@sun.com> Thanks! Paul Mark Reinhold wrote: >> Date: Fri, 08 May 2009 17:26:52 -0400 >> From: paul.hohensee at sun.com >> > > >> Yes. It restores the behavior previous to this changeset >> >> http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/6bdd6923ba16 >> >> so it's been thoroughly tested. >> >> UseNUMA is used for both specjbb2005 single jvm runs and specjvm2008 runs, >> so it's fairly critical. Also, free_memory() is only used by the NUMA >> collector. >> We're going to push it into hs15 for 6u14p, for which it's the last >> minute as well. >> > > Okay, thanks for the explanation. I'll approve this one. > > - Mark > From mr at sun.com Tue May 12 11:50:03 2009 From: mr at sun.com (Mark Reinhold) Date: Tue, 12 May 2009 11:50:03 -0700 Subject: 6839839 access checking logic -- for M3 b59? Message-ID: <20090512185003.B83EE5CE1@eggemoggin.niobe.net> I see you've requested approval for this, but I saw Xiomara in the hallway and she said you're still working on it. Just so you know, I'm willing to approve pretty much any small, 292-only changes so long as all your tests still pass and, preferably, the 292-enhanced JRuby still runs on it. - Mark From Paul.Hohensee at Sun.COM Tue May 12 14:58:14 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Tue, 12 May 2009 17:58:14 -0400 Subject: One last (there's no time for another) Hotspot approval request for b59 Message-ID: <4A09F0F6.3000206@sun.com> 6840196 NUMA allocator: crash in fastdebug during startup on Linux Turns out we don't actually test UseNUMA running on a NUMA-enabled Linux, so we've just discovered and fixed a problem loading the NUMA library. Without it, UseNUMA won't work on the latest Linuxen. A simple change such that if it doesn't work then we haven't made anything worse than it already is. SQE has given us a PIT waiver for it. The review request is "For some reason dlsym in Linux started to find the latest version of the symbol instead of the oldest, which I think it is supposed to do. And since NUMA API in linux has changed in the 2.0 version of the library now we need to explicitly specify the version number of the symbol when running with this library. We also need to continue loading the base version of the symbols with the 1.0 version of the library. The fix is to load NUMA API symbols in two stages. The first stage would try to load symbols with "libnuma_1.1" (the way they are in the >2.0 versions). If that doesn't work the second stage loads them the normal way. Webrev: http://cr.openjdk.java.net/~iveresov/6840196/webrev.00 Testing: jbb2005 on Linuxes with different versions of the library." Thanks, Paul From mr at sun.com Tue May 12 15:04:45 2009 From: mr at sun.com (Mark Reinhold) Date: Tue, 12 May 2009 15:04:45 -0700 Subject: One last (there's no time for another) Hotspot approval request for b59 In-Reply-To: paul.hohensee@sun.com; Tue, 12 May 2009 17:58:14 EDT; <4A09F0F6.3000206@sun.com> Message-ID: <20090512220445.1A46D5CE1@eggemoggin.niobe.net> > Date: Tue, 12 May 2009 17:58:14 -0400 > From: paul.hohensee at sun.com > 6840196 NUMA allocator: crash in fastdebug during startup on Linux > > Turns out we don't actually test UseNUMA running on a NUMA-enabled > Linux, so we've just discovered and fixed a problem loading the NUMA > library. Without it, UseNUMA won't work on the latest Linuxen. A > simple change such that if it doesn't work then we haven't made > anything worse than it already is. > > SQE has given us a PIT waiver for it. I'll approve this, but on the condition that someone actually test it on a NUMA-enabled Linux box before pushing the change. - Mark From Paul.Hohensee at Sun.COM Tue May 12 15:12:29 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Tue, 12 May 2009 18:12:29 -0400 Subject: One last (there's no time for another) Hotspot approval request for b59 In-Reply-To: <20090512220445.1A46D5CE1@eggemoggin.niobe.net> References: <20090512220445.1A46D5CE1@eggemoggin.niobe.net> Message-ID: <4A09F44D.2020901@sun.com> Igor? Paul Mark Reinhold wrote: >> Date: Tue, 12 May 2009 17:58:14 -0400 >> From: paul.hohensee at sun.com >> > > >> 6840196 NUMA allocator: crash in fastdebug during startup on Linux >> >> Turns out we don't actually test UseNUMA running on a NUMA-enabled >> Linux, so we've just discovered and fixed a problem loading the NUMA >> library. Without it, UseNUMA won't work on the latest Linuxen. A >> simple change such that if it doesn't work then we haven't made >> anything worse than it already is. >> >> SQE has given us a PIT waiver for it. >> > > I'll approve this, but on the condition that someone actually test it on > a NUMA-enabled Linux box before pushing the change. > > - Mark > From John.Rose at Sun.COM Tue May 12 13:44:01 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 12 May 2009 13:44:01 -0700 Subject: 6839839 access checking logic -- for M3 b59? In-Reply-To: <20090512185003.B83EE5CE1@eggemoggin.niobe.net> References: <20090512185003.B83EE5CE1@eggemoggin.niobe.net> Message-ID: <046E7D64-F7F3-4FDA-8B0B-2485F85113F7@Sun.COM> Thanks! Yes, I have a few such changes (point fixes to JSR 292 code only) for 6839839, they pass my tests, and I will be passing them to Xiomara shortly. -- John On May 12, 2009, at 11:50 AM, Mark Reinhold wrote: > I see you've requested approval for this, but I saw Xiomara in > the hallway and she said you're still working on it. > > Just so you know, I'm willing to approve pretty much any small, > 292-only changes so long as all your tests still pass and, > preferably, the 292-enhanced JRuby still runs on it. > > - Mark From Igor.Veresov at Sun.COM Tue May 12 15:29:12 2009 From: Igor.Veresov at Sun.COM (Igor Veresov) Date: Tue, 12 May 2009 15:29:12 -0700 Subject: One last (there's no time for another) Hotspot approval request for b59 In-Reply-To: <4A09F44D.2020901@sun.com> References: <20090512220445.1A46D5CE1@eggemoggin.niobe.net> <4A09F44D.2020901@sun.com> Message-ID: <4A09F838.8080005@sun.com> Paul, Mark -- I've tested the fix on the affected platforms. So, I'm sure it's going to work OK. igor On 5/12/09 3:12 PM, Paul Hohensee wrote: > Igor? > > Paul > > Mark Reinhold wrote: >>> Date: Tue, 12 May 2009 17:58:14 -0400 >>> From: paul.hohensee at sun.com >> >>> 6840196 NUMA allocator: crash in fastdebug during startup on Linux >>> >>> Turns out we don't actually test UseNUMA running on a NUMA-enabled >>> Linux, so we've just discovered and fixed a problem loading the NUMA >>> library. Without it, UseNUMA won't work on the latest Linuxen. A >>> simple change such that if it doesn't work then we haven't made >>> anything worse than it already is. >>> >>> SQE has given us a PIT waiver for it. >> >> I'll approve this, but on the condition that someone actually test it on >> a NUMA-enabled Linux box before pushing the change. >> >> - Mark From mr at sun.com Tue May 12 15:34:09 2009 From: mr at sun.com (Mark Reinhold) Date: Tue, 12 May 2009 15:34:09 -0700 Subject: One last (there's no time for another) Hotspot approval request for b59 In-Reply-To: igor.veresov@sun.com; Tue, 12 May 2009 15:29:12 PDT; <4A09F838.8080005@sun.com> Message-ID: <20090512223409.6D0EE5CE1@eggemoggin.niobe.net> > Date: Tue, 12 May 2009 15:29:12 -0700 > From: igor.veresov at sun.com > I've tested the fix on the affected platforms. So, I'm sure it's going > to work OK. Okay, thanks. - Mark From Xiomara.Jayasena at Sun.COM Tue May 12 19:01:02 2009 From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena) Date: Tue, 12 May 2009 19:01:02 -0700 Subject: 6839839 access checking logic -- for M3 b59? In-Reply-To: <046E7D64-F7F3-4FDA-8B0B-2485F85113F7@Sun.COM> References: <20090512185003.B83EE5CE1@eggemoggin.niobe.net> <046E7D64-F7F3-4FDA-8B0B-2485F85113F7@Sun.COM> Message-ID: <4A0A29DE.7080703@sun.com> Most builds completed fine. The windows-i586 build failed due to a networking problem during the digital signing part. Just to play it safe, I re-running the windows-i586 build. I will wait for that to complete prior to pushing your changes to the master repos. -Xiomara John Rose wrote: > Thanks! Yes, I have a few such changes (point fixes to JSR 292 code > only) for 6839839, they pass my tests, and I will be passing them to > Xiomara shortly. > > -- John > > On May 12, 2009, at 11:50 AM, Mark Reinhold wrote: > >> I see you've requested approval for this, but I saw Xiomara in >> the hallway and she said you're still working on it. >> >> Just so you know, I'm willing to approve pretty much any small, >> 292-only changes so long as all your tests still pass and, >> preferably, the 292-enhanced JRuby still runs on it. >> >> - Mark >