From volker.simonis at gmail.com Tue Jun 2 05:40:43 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 2 Jun 2009 14:40:43 +0200 Subject: Hotspot shell games In-Reply-To: <4A22CD18.9020002@sun.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905281752v5f925e7cm9390a2eac4a6d600@mail.gmail.com> <4A1F366E.9010801@sun.com> <4A1F38A2.2090505@sun.com> <17c6771e0905290456j7c3b62f8xee36460943abe374@mail.gmail.com> <4A200AEA.3050809@sun.com> <17c6771e0905301732n1b87d8b6we0efe1af83f6a794@mail.gmail.com> <4A22CD18.9020002@sun.com> Message-ID: Sorry for the late replay (public holidays in Germany:) Please see my comments inline... On 5/31/09, Kelly O'Hair wrote: > > > Andrew John Hughes wrote: > > > 2009/5/29 Kelly O'Hair : > > > > > (removed jdk7-dev from this discussion) > > > > > > Andrew John Hughes wrote: > > > > > > > 2009/5/29 Erik Trimble : > > > > > > > [snip] > > > > > > > > > > > > For now, though, we need to decide how to handle HSX vs Open6 vs. > IceTea. > > > > > > > > > Simplest solution would be to just remove it from OpenJDK6 and use HSX > > > > as the upstream. I don't see an advantage to pulling in to OpenJDK6, > > > > given there is already a 'stable' branch of HSX. > > > > > > > I would prefer to keep a hotspot repository in the openjdk6 forest, just > > > for the sake of having a buildable and complete source base. > > > > > > > I can see the advantage, though I would guess the number of people > > doing OpenJDK6 builds is far smaller than those doing IcedTea builds > > which has been deleting the OpenJDK6 repo and replacing it for months > > now. If the OpenJDK6 repo is again allowed to bit-rot, then we're > > likely to have to do this again. We'd obviously prefer to be working > > on a common upstream rather than having effectively two communities. > > > > It doesn't matter to me which is being built more or less, I just want > to make sure that OpenJDK6 is complete and does build, and work. > I also want to open it up as much as possible in terms of others > pushing changes in. I'm sure we can work this out in an acceptable way > for all concerned... read on... > > > > > > > > > I would also like to have some level of confidence as to which hotspot > > > is the default one for the openjdk6 project. > > > Let's not leave a partial jdk6 forest sitting out there. > > > > > > > > > > My main concern is maintenance. If what is there is maintained > > regularly, I don't care too much either way. That said, I'd prefer to > > see less duplication though, and this also extends to CORBA, JAXP and > > JAXWS as Joe already mentioned. > > > > I agree, and I'm all in favor. But having a complete OpenJDK6 tree, > including hotspot doesn't change that, it's just a clone of a repository > that represents what we know works. > If the IcedTea team said that they tried Hotspot version 3,246 and it > worked for them and looked solid, then hey, great, push those changesets > into the openjdk6 hotspot repository. > Or we work out some other way to update it, I'm open to suggestions, > I just would like to see 'a clone' of 'a hotspot' repository available > with the openjdk6 forest of repositories. > > > > > > > > > To me the decision that needs to be made is whether you want the > > > openjdk6 hotspot repository (jdk6/hotspot) 'related' to the other > > > hotspot repositories, like hsx/hsx14/master is related to jdk7/hotspot. > > > > > > > It isn't related; hsx includes several build drops that were never in > > the public HotSpot repositories and which we had to wait over three > > months for. > > > > When I say 'related' I'm referring to the ability to pull/push mercurial > changesets between the repositories without transplanting or reapplying > patches. And the hsx repository is related to the public repositories, > they just might not ne in sync or be proper subsets of each other at times. > > > > > > > > > It doesn't have to be, and there are advantages and disadvantages to > > > both approaches. > > > None of the non-hotspot repositories in the openjdk6 forest are related > > > to the jdk7 repositories, making them pretty independent from jdk7, > > > > > > > Which is sensible, given 6 has to be stable. It being based off jdk7 > > is merely an issue of when things were released under the GPL, as I > > believe you or Joe have blogged about before. > > > > No it's more than that, the sources themselves have a relationship between > openjdk6 and openjdk7, but the repositories themselves are not related, > you cannot pull/push changesets between these repositories. > You can reapply patches and re-create new changesets that match from > one to the other, and Mercurial makes that easy, but they are not the > same changesets. > > I'm thinking that they should be related, and most of the time be > proper subsets of each other in terms of what changesets are in them. > This gives us a degree of exactness you don't get when changesets are > re-created frpm patches. Assuming we can do it or even agree to it. > > > > > > > > > but hotspot is somewhat special, and the express model I support, so... > > > > > > My suggestions... > > > * Ignore hsx/hsx14, it's a drop not a development tree > > > > > > > What??? I don't believe any discussions around HSX ever being about it > > being just a drop. It's meant to be a stability branch of hs14 for > > use in OpenJDK6 and Sun's JDK6 releases. If it was a drop, why do a > > forest at all and not just update OpenJDK6? > > > > My definition of 'drop' here was that it is not intended to be a > two-way open street as I understood the purpose. > A simple source tarball could have worked, but since there was always > a chance of last minute hs14 changes, a repository makes things easier, > granted it sounds like it was updated a little slowly with the last few > changes. > My point in the comment is that, as I understand it, hs14 is for all > intents and purposes, done. > Maybe I have that wrong, but my assumption is that the team is and has > moved on to the next hotspot express release, and hs14 is no longer > a priority. > I'm not sure if that's true - there's a 6u15-ea-src-b01 out there which has a HS 14.1 b01 (not sure what that is, does 14.1b01 come after 14.0b17???). But at least it seems to be a HS 14 and therefore all the hotspot changes to 6u15 should be instantly visible in hsx/hsx14. But there's an IMPORTANT point here: once the Java 6 train moves to a HS 15 we need a hsx/hsx15 repository and from my point of view we need it as fast as possible, to avoid all the confusion that we had with hsx14! > > > > > > > > * Decide to make the jdk6 and jdk7 repositories 'related' > > > > > > > Impossible, unless I misunderstand what you mean by 'related'. > > > > Related to me means that both repositories have the same "changeset 0". > What I am suggesting is that occasionally, after a sync, the jdk6 repo > would be > a proper subset of the jdk7 repo. > > > > > > > > > * Tag the rev in the jdk7/hotspot repo with a name jdk6-b17, the > > > rev that matches what is in the hsx14 repo > > > > > > > Again there is no hs14b11...hs14b16 in the public HotSpot repository. > > > > Actually I think there is, we just are not recording it in the changeset > tags. > > > > That's what sparked the whole discussion that lead to HSX in the first > > place. Sun took HotSpot 14 'underground' and out of the public eye as > > regards further stability work. With hsx, we finally seem to have > > reversed this process by the release of hs14b11...hs14b16 and I'd > > expect to see further releases appear there too. > > > > I'm just not sure you will be getting what you are expecting with this, > again, I thought hsx14 was a done deal for the most part. > > > > > > > > > * Toss the existing jdk6/hotspot repo and replace it with a repo > > > created with: > > > hg clone -r jdk6-b17 > http://hg.openjdk.java.net/jdk7/hotspot > > > jdk6/hotspot > > > > > > > > > > I think the only options are to pull in changeset 0 from hsx to rebase > > the HotSpot repo on that, or (simpler) replace it with a clone of hsx. > > The former would preserve the commit history and would be more useful > > over time IMO. > > > > I'm very confused now, I think we just said the same thing, or something > extremely similar. > > > > > > > > > Changes going into jdk6/hotspot should be rare, critical, and should > > > eventually be pushed back into jdk7/hotspot, indeed some critical fixes > > > may get transplanted from jdk7/hotspot to jdk6/hotspot. > > > If at some point it's decided to upgrade jdk6/hotspot to a newer rev, > > > so be it, easy to do. > > > > > > > > > > I think changes should just go to hsx and then feed into OpenJDK6 > > through regular pulls, if we plan to maintain a repo. there. > > > > EXACTLY! That is what I am suggesting for OpenJDK6, just a clone. > > Except you say "hsx" I say "jdk7/hotspot", to me they are the same, > or "the latest hotspot express where all the latest work is done". > > > > > > > > > And for heavens sake, start adding some hsx-* tags to the hotspot > repository > > > so we can easily clone hsx versions from the tag name, you could also > use > > > the hsx tag to hold the build number, I can help with that. > > > > > > > > > > Now this I agree on :) > > > > Good... I'll keep pushing on this then. > > --- > > Erik, > > Let's start looking into hsx-* tags!!! ;^) > > -kto > > > > > > > > > -kto > > > > > > > > > > > > > > > > > > > > > From volker.simonis at gmail.com Tue Jun 2 06:00:01 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 2 Jun 2009 15:00:01 +0200 Subject: Hotspot shell games In-Reply-To: <4A217C46.2050101@sun.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <17c6771e0905281752v5f925e7cm9390a2eac4a6d600@mail.gmail.com> <4A1F366E.9010801@sun.com> <4A1F38A2.2090505@sun.com> <17c6771e0905290456j7c3b62f8xee36460943abe374@mail.gmail.com> <4A200AEA.3050809@sun.com> <4A2022FF.8040303@sun.com> <4A217C46.2050101@sun.com> Message-ID: Your proposals look ok to me. There's only one point I would like to add: until now, the OpenJDK repositories are quite "linear" in the sense that we created new repositories for every bigger development line (i.e. branch) like for example OpenJDK 6, Sun JDK updates, HSX, ... Now, if we start to integrate all these branches back into the main OpenJDK repository, we get a much more comlex repository with a lot of branches there. Not sure if that's a problem, it just came to my mind. In fact it's like if we would have no hsx/hsx14 at all but just keep a parallel "diverged line of development" for it in the main OpenJDK/hotspot repository (i.e. keep parallel heads there). On 5/30/09, Kelly O'Hair wrote: > Sigh... our home grown bug system does have these strange shadow bugs, > but in general people are told to not refer to them directly. > So whether it's jdk5, jdk6, or jdk7 people usually use the 6NNNNNN > number, or are told to. Not that your suggestion of using the 2NNNNNN > bugs would not work. > I was kind of wishing we could just start using bugzilla numbers. :^( > > --- > I'm thinking about proposing a change to the jcheck rule on > a single bugid being used once in a repository. > > What if we could allow an optional '-N' or '-text' after the bugid, > e.g. allow additional changesets that look like (just examples) > > 6123456-1: Synopsis ... > Summary: Additional change needed due to ... > > 6123456-workaround: Synopsis ... > Summary: Temporary workaround until more formal fix ... > > 6123456-transplant: Synopsis ... > Summary: Transplant of fix from jdk7 repository > > 6123456-testcase: Synopsis ... > Summary: Temporarily ignore testcase until bug fixed... > > 6123456-phase88: Synopsis ... > Summary: Phase 88 of doc changes for milestone 9,564 ;^) > > Where the pattern would be either a 6 or 7 digit number with an > optional set of characters. > The rule then changes to that pattern (up to the ':') cannot be repeated > in any other changeset. > Transplants are then allowed, but some changes to the changeset comment > to identify them as such would be needed. > > Just ideas.... All to avoid having to file extra and needless bugs. > > Comments? > > -kto > > > > Volker Simonis wrote: > > > Thank you for the detailed explanation. It was indeed the situation > > with the same changesets beeing applied in parallel to both > > repositories that worried me. But aren't there already different > > BugIds for the same change in the Bug database (those strange "shadow" > > bugids starting with 2***) for exactly this purpose? > > > > Volker > > > > On Fri, May 29, 2009 at 8:01 PM, Kelly O'Hair wrote: > > > > > > > > Volker Simonis wrote: > > > > > > > > > > > > * Tag the rev in the jdk7/hotspot repo with a name jdk6-b17, the > > > > > rev that matches what is in the hsx14 repo > > > > > > > > > Is this really possible? I thought the HS which is now in 6u14 (and in > > > > HSX14) was branched from the jdk7/hotspot sometimes around hotspot > > > > build 9/10 of the jdk7/hotspot. Afterwards, the hotspot version was > > > > incremented to 15 in jdk7/hotspot while there have been about six more > > > > builds of HS 14 in the HSX14 repository. From my understanding, the > > > > change history in jdk7/hotspot and HSX14 is different after HSX has > > > > been branched off from jdk7/hotspot and I can't imagine how one can > > > > now find a changeset in jdk7/hotspot which matches the hotspot version > > > > in HSX14. After all, the whole purpose of branching HSX14 is to > > > > stabilize it while the development can proceed in jdk7/hotspot. Or am > > > > I missing something here? > > > > > > > Mercurial tags can be created after the fact. A tag is just a reference > > > or name to a changeset ID, they can also be updated or changed later. > > > They are very simple things. > > > > > > I'll ignore "HSX14", and call it "jdk6/hotspot", but if you like, you > can > > > replace the names as you read this. ;^) > > > > > > If jdk6/hotspot work is done in a jdk6/hotspot repository, and new > > > changesets are > > > added or new tags created, you should be able to pull those changesets > > > into jdk7/hotspot, merge and commit them there too. > > > The end result is that all the jdk6/hotspot changesets are in > jdk7/hotspot, > > > then you could 'hg clone -r jdk6-bNN' from either repository and get the > > > exact same thing. > > > > > > The trick is to create jdk6/hotspot changesets in an jdk6/hotspot > repository > > > so that the graph of changesets for jdk6/hotspot are all connected > together. > > > The sync to jdk7/hotspot effectively adds any jdk6/hotspot changesets > and > > > merges > > > with the current jdk7/hotspot tip, creating a new jdk7/hotspot tip. > > > > > > The jdk6/hotspot repository acts as a branch, yet no hg branches are > used. > > > Someone would occasionally need to make sure the jdk6/hotspot changes > that > > > are not in jdk7/hotspot get pulled over (a sync). > > > > > > The tricky part is transplanting or cherry picking 1 changeset from > > > jdk7/hotspot back to jdk6/hotspot without accepting the whole graph > > > of changesets above it. Unless we relax the jcheck rules around this, > > > two changesets with the same bugid cannot exist in one repository, so > > > a new bugid is needed to do any transplants (where a new changeset is > > > created for the same patch or code change). > > > > > > -kto > > > > > > > > > > Regards, > > > > Volker > > > > > > > > > > From aph at redhat.com Tue Jun 2 07:54:49 2009 From: aph at redhat.com (aph at redhat.com) Date: Tue, 02 Jun 2009 14:54:49 +0000 Subject: hg: jdk6/jdk6/jdk: 4428022: System.out.println(0.001) outputs 0.0010 Message-ID: <20090602145506.0FACBEEC8@hg.openjdk.java.net> Changeset: 8159687b6316 Author: aph Date: 2009-06-02 15:46 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/8159687b6316 4428022: System.out.println(0.001) outputs 0.0010 Reviewed-by: darcy ! src/share/classes/sun/misc/FloatingDecimal.java + test/java/lang/Double/ToString.java From gnu_andrew at member.fsf.org Tue Jun 2 11:43:30 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 2 Jun 2009 19:43:30 +0100 Subject: Hotspot shell games In-Reply-To: <4A22CD18.9020002@sun.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905281752v5f925e7cm9390a2eac4a6d600@mail.gmail.com> <4A1F366E.9010801@sun.com> <4A1F38A2.2090505@sun.com> <17c6771e0905290456j7c3b62f8xee36460943abe374@mail.gmail.com> <4A200AEA.3050809@sun.com> <17c6771e0905301732n1b87d8b6we0efe1af83f6a794@mail.gmail.com> <4A22CD18.9020002@sun.com> Message-ID: <17c6771e0906021143x1abd3e6dra2ee62dfbfd5eec1@mail.gmail.com> 2009/5/31 Kelly O'Hair : > > > Andrew John Hughes wrote: >> >> 2009/5/29 Kelly O'Hair : >>> >>> (removed jdk7-dev from this discussion) >>> >>> Andrew John Hughes wrote: >>>> >>>> 2009/5/29 Erik Trimble : >>> >>> [snip] >>>>> >>>>> For now, though, we need to decide how to handle HSX vs Open6 vs. >>>>> IceTea. >>>> >>>> Simplest solution would be to just remove it from OpenJDK6 and use HSX >>>> as the upstream. ?I don't see an advantage to pulling in to OpenJDK6, >>>> given there is already a 'stable' branch of HSX. >>> >>> I would prefer to keep a hotspot repository in the openjdk6 forest, just >>> for the sake of having a buildable and complete source base. >> >> I can see the advantage, though I would guess the number of people >> doing OpenJDK6 builds is far smaller than those doing IcedTea builds >> which has been deleting the OpenJDK6 repo and replacing it for months >> now. ?If the OpenJDK6 repo is again allowed to bit-rot, then we're >> likely to have to do this again. ?We'd obviously prefer to be working >> on a common upstream rather than having effectively two communities. > > It doesn't matter to me which is being built more or less, I just want > to make sure that OpenJDK6 is complete and does build, and work. > I also want to open it up as much as possible in terms of others > pushing changes in. I'm sure we can work this out in an acceptable way > for all concerned... read on... > >> >>> I would also like to have some level of confidence as to which hotspot >>> is the default one for the openjdk6 project. >>> Let's not leave a partial jdk6 forest sitting out there. >>> >> >> My main concern is maintenance. ?If what is there is maintained >> regularly, I don't care too much either way. ?That said, I'd prefer to >> see less duplication though, and this also extends to CORBA, JAXP and >> JAXWS as Joe already mentioned. > > I agree, and I'm all in favor. But having a complete OpenJDK6 tree, > including hotspot doesn't change that, it's just a clone of a repository > that represents what we know works. > If the IcedTea team said that they tried Hotspot version 3,246 and it > worked for them and looked solid, then hey, great, push those changesets > into the openjdk6 hotspot repository. > Or we work out some other way to update it, I'm open to suggestions, > I just would like to see 'a clone' of 'a hotspot' repository available > with the openjdk6 forest of repositories. > My reticence is mainly because getting changes upstream has been so slow. That seems to be changing though. I agree with your feelings about OpenJDK6 being 'complete'. >> >>> To me the decision that needs to be made is whether you want the >>> openjdk6 hotspot repository (jdk6/hotspot) 'related' to the other >>> hotspot repositories, like hsx/hsx14/master is related to jdk7/hotspot. >> >> It isn't related; hsx includes several build drops that were never in >> the public HotSpot repositories and which we had to wait over three >> months for. > > When I say 'related' I'm referring to the ability to pull/push mercurial > changesets between the repositories without transplanting or reapplying > patches. And the hsx repository is related to the public repositories, > they just might not ne in sync or be proper subsets of each other at times. > Ok, they are related in one direction sure; hsx and jdk7/hotspot match up to hs14b10. But at that point, one continues up to hs14b11, and the other starts on hs15b01 up to hs16b03 (in JDK7 b59). We don't want hs15 or hs16 in 6 until they have proved stable enough; that's exactly why IcedTea was using a specific HotSpot 7 changeset of hs14b10 rather than tip prior to the availability of hsx. But the changesets needed for OpenJDK6 simply aren't in the jdk7 forest and they can't really be inserted back in the past somewhere. >> >>> It doesn't have to be, and there are advantages and disadvantages to >>> both approaches. >>> None of the non-hotspot repositories in the openjdk6 forest are related >>> to the jdk7 repositories, making them pretty independent from jdk7, >> >> Which is sensible, given 6 has to be stable. ?It being based off jdk7 >> is merely an issue of when things were released under the GPL, as I >> believe you or Joe have blogged about before. > > No it's more than that, the sources themselves have a relationship between > openjdk6 and openjdk7, but the repositories themselves are not related, > you cannot pull/push changesets between these repositories. > You can reapply patches and re-create new changesets that match from > one to the other, and Mercurial makes that easy, but they are not the > same changesets. > Tell me about it... :) Being able to do hg export/import would be easier. > I'm thinking that they should be related, and most of the time be > proper subsets of each other in terms of what changesets are in them. > This gives us a degree of exactness you don't get when changesets are > re-created frpm patches. ?Assuming we can do it or even agree to it. > The immediate problem I see is that OpenJDK6 is based on a version of OpenJDK7 not represented in Mercurial. Only b24 and on are, and I believe OpenJDK6 was forked prior to this. >> >>> but hotspot is somewhat special, and the express model I support, so... >>> >>> My suggestions... >>> ?* Ignore hsx/hsx14, it's a drop not a development tree >> >> What??? I don't believe any discussions around HSX ever being about it >> being just a drop. ?It's meant to be a stability branch of hs14 for >> use in OpenJDK6 and Sun's JDK6 releases. ?If it was a drop, why do a >> forest at all and not just update OpenJDK6? > > My definition of 'drop' here was that it is not intended to be a > two-way open street as I understood the purpose. > A simple source tarball could have worked, but since there was always > a chance of last minute hs14 changes, a repository makes things easier, > granted it sounds like it was updated a little slowly with the last few > changes. > My point in the comment is that, as I understand it, hs14 is for all > intents and purposes, done. > Maybe I have that wrong, but my assumption is that the team is and has > moved on to the next hotspot express release, and hs14 is no longer > a priority. My understanding is that while development for 7 continued to hs15 and hs166 in the public jdk7/hotspot repositories, a fork was silently created inside Sun of hs14 for the 6 update releases. This is what has now finally been published as hsx. The fork came as a shock to me, and it would have been a whole lot better if it had been created in public to begin with. Thus, my understanding is that hsx will continue to evolve while a version of hs14 is needed for the 6 updates. > >> >>> ?* Decide to make the jdk6 and jdk7 repositories 'related' >> >> Impossible, unless I misunderstand what you mean by 'related'. > > Related to me means that both repositories have the same "changeset 0". > What I am suggesting is that occasionally, after a sync, the jdk6 repo would > be > a proper subset of the jdk7 repo. > Would be nice, but see my comment about b24 above. >> >>> ?* Tag the rev in the jdk7/hotspot repo with a name jdk6-b17, the >>> ? rev that matches what is in the hsx14 repo >> >> Again there is no hs14b11...hs14b16 in the public HotSpot repository. > > Actually I think there is, we just are not recording it in the changeset > tags. No there isn't. We wouldn't have made a fuss for three months about it if there was :) > >> That's what sparked the whole discussion that lead to HSX in the first >> place. ?Sun took HotSpot 14 'underground' and out of the public eye as >> regards further stability work. ?With hsx, we finally seem to have >> reversed this process by the release of hs14b11...hs14b16 and I'd >> expect to see further releases appear there too. > > I'm just not sure you will be getting what you are expecting with this, > again, I thought hsx14 was a done deal for the most part. > Nothing would surprise me at this stage. To be honest, I'm just getting a little sick and tired of all these forks, especially when (to the outside world) many seem unnecessary. With IcedTea, we deliberately went down a more difficult path of patching the upstream source and trying to contribute the patches upstream rather than just forking. This was done for the good of the community. What Sun did with hs14 seems to go against the entire purpose of the OpenJDK project and I'd like to assume it was just a mistake. Even when JDK7 is released, I don't see 6 disappearing overnight. By that time, I think we want to be in a situation where OpenJDK6 is an open-source version of what Sun shipped as the last 6 update release (well minus the plugin but that's a whole other story). There's no real reason for this not to be the case AFAICS except the need for time and effort to get everything out in the open and into OpenJDK6. >> >>> ?* Toss the existing jdk6/hotspot repo and replace it with a repo >>> ? created with: >>> ? ? ? hg clone -r jdk6-b17 http://hg.openjdk.java.net/jdk7/hotspot >>> jdk6/hotspot >>> >> >> I think the only options are to pull in changeset 0 from hsx to rebase >> the HotSpot repo on that, or (simpler) replace it with a clone of hsx. >> ?The former would preserve the commit history and would be more useful >> over time IMO. > > I'm very confused now, I think we just said the same thing, or something > extremely similar. > We're saying the same, except I'm talking about using hsx while you're talking about using jdk7/hotspot. The latter would lose us the 6 new build drops of hs14. >> >>> Changes going into jdk6/hotspot should be rare, critical, and should >>> eventually be pushed back into jdk7/hotspot, indeed some critical fixes >>> may get transplanted from jdk7/hotspot to jdk6/hotspot. >>> If at some point it's decided to upgrade jdk6/hotspot to a newer rev, >>> so be it, easy to do. >>> >> >> I think changes should just go to hsx and then feed into OpenJDK6 >> through regular pulls, if we plan to maintain a repo. there. > > EXACTLY! That is what I am suggesting for OpenJDK6, just a clone. > > Except you say "hsx" I say "jdk7/hotspot", to me they are the same, > or "the latest hotspot express where all the latest work is done". > Unfortunately they aren't the same. I wish they were. >> >>> And for heavens sake, start adding some hsx-* tags to the hotspot >>> repository >>> so we can easily clone hsx versions from the tag name, you could also use >>> the hsx tag to hold the build number, I can help with that. >>> >> >> Now this I agree on :) > > Good... ?I'll keep pushing on this then. > > --- > > Erik, > > Let's start looking into hsx-* tags!!! ;^) > > -kto > >> >>> -kto >>> >>> >>> >> >> >> > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From volker.simonis at gmail.com Tue Jun 2 12:08:12 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 2 Jun 2009 21:08:12 +0200 Subject: Hotspot shell games In-Reply-To: <17c6771e0906021143x1abd3e6dra2ee62dfbfd5eec1@mail.gmail.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905281752v5f925e7cm9390a2eac4a6d600@mail.gmail.com> <4A1F366E.9010801@sun.com> <4A1F38A2.2090505@sun.com> <17c6771e0905290456j7c3b62f8xee36460943abe374@mail.gmail.com> <4A200AEA.3050809@sun.com> <17c6771e0905301732n1b87d8b6we0efe1af83f6a794@mail.gmail.com> <4A22CD18.9020002@sun.com> <17c6771e0906021143x1abd3e6dra2ee62dfbfd5eec1@mail.gmail.com> Message-ID: On 6/2/09, Andrew John Hughes wrote: > 2009/5/31 Kelly O'Hair : > > > > > > > Andrew John Hughes wrote: > >> > >> 2009/5/29 Kelly O'Hair : > >>> > >>> (removed jdk7-dev from this discussion) > >>> > >>> Andrew John Hughes wrote: > >>>> > >>>> 2009/5/29 Erik Trimble : > >>> > >>> [snip] > >>>>> > >>>>> For now, though, we need to decide how to handle HSX vs Open6 vs. > >>>>> IceTea. > >>>> > >>>> Simplest solution would be to just remove it from OpenJDK6 and use HSX > >>>> as the upstream. I don't see an advantage to pulling in to OpenJDK6, > >>>> given there is already a 'stable' branch of HSX. > >>> > >>> I would prefer to keep a hotspot repository in the openjdk6 forest, just > >>> for the sake of having a buildable and complete source base. > >> > >> I can see the advantage, though I would guess the number of people > >> doing OpenJDK6 builds is far smaller than those doing IcedTea builds > >> which has been deleting the OpenJDK6 repo and replacing it for months > >> now. If the OpenJDK6 repo is again allowed to bit-rot, then we're > >> likely to have to do this again. We'd obviously prefer to be working > >> on a common upstream rather than having effectively two communities. > > > > It doesn't matter to me which is being built more or less, I just want > > to make sure that OpenJDK6 is complete and does build, and work. > > I also want to open it up as much as possible in terms of others > > pushing changes in. I'm sure we can work this out in an acceptable way > > for all concerned... read on... > > > >> > >>> I would also like to have some level of confidence as to which hotspot > >>> is the default one for the openjdk6 project. > >>> Let's not leave a partial jdk6 forest sitting out there. > >>> > >> > >> My main concern is maintenance. If what is there is maintained > >> regularly, I don't care too much either way. That said, I'd prefer to > >> see less duplication though, and this also extends to CORBA, JAXP and > >> JAXWS as Joe already mentioned. > > > > I agree, and I'm all in favor. But having a complete OpenJDK6 tree, > > including hotspot doesn't change that, it's just a clone of a repository > > that represents what we know works. > > If the IcedTea team said that they tried Hotspot version 3,246 and it > > worked for them and looked solid, then hey, great, push those changesets > > into the openjdk6 hotspot repository. > > Or we work out some other way to update it, I'm open to suggestions, > > I just would like to see 'a clone' of 'a hotspot' repository available > > with the openjdk6 forest of repositories. > > > > > My reticence is mainly because getting changes upstream has been so > slow. That seems to be changing though. I agree with your feelings > about OpenJDK6 being 'complete'. > > > >> > >>> To me the decision that needs to be made is whether you want the > >>> openjdk6 hotspot repository (jdk6/hotspot) 'related' to the other > >>> hotspot repositories, like hsx/hsx14/master is related to jdk7/hotspot. > >> > >> It isn't related; hsx includes several build drops that were never in > >> the public HotSpot repositories and which we had to wait over three > >> months for. > > > > When I say 'related' I'm referring to the ability to pull/push mercurial > > changesets between the repositories without transplanting or reapplying > > patches. And the hsx repository is related to the public repositories, > > they just might not ne in sync or be proper subsets of each other at times. > > > > > Ok, they are related in one direction sure; hsx and jdk7/hotspot match > up to hs14b10. But at that point, one continues up to hs14b11, and > the other starts on hs15b01 up to hs16b03 (in JDK7 b59). We don't > want hs15 or hs16 in 6 until they have proved stable enough; that's > exactly why IcedTea was using a specific HotSpot 7 changeset of > hs14b10 rather than tip prior to the availability of hsx. But the > changesets needed for OpenJDK6 simply aren't in the jdk7 forest and > they can't really be inserted back in the past somewhere. > This was my first thought too, but after rereading Kellys mails and rethinking the whole story I think Kelly is right and it's possible, exactly because the repositories are related. You can think of it as creating a new branch in the jdk7/hotspot repository at the point where hs14 was forked off with a new head which is the tip of the current hsx14 repo (please see my previous mail in this thread - after all a Mercurial repo is a real tree and you don't necessarily have to merge all the branches in the end). The only glitch is the jcheck problem with duplicate bug ids mentioned by Kelly. The one thing where I however strongly agree with you is that Sun should do the stabilization work in the open from the very beginning, and not after the work is finished - we'll see if this will be true at the point where HS15/HSX15 will appear in Java 6. > > >> > >>> It doesn't have to be, and there are advantages and disadvantages to > >>> both approaches. > >>> None of the non-hotspot repositories in the openjdk6 forest are related > >>> to the jdk7 repositories, making them pretty independent from jdk7, > >> > >> Which is sensible, given 6 has to be stable. It being based off jdk7 > >> is merely an issue of when things were released under the GPL, as I > >> believe you or Joe have blogged about before. > > > > No it's more than that, the sources themselves have a relationship between > > openjdk6 and openjdk7, but the repositories themselves are not related, > > you cannot pull/push changesets between these repositories. > > You can reapply patches and re-create new changesets that match from > > one to the other, and Mercurial makes that easy, but they are not the > > same changesets. > > > > > Tell me about it... :) Being able to do hg export/import would be easier. > > > > I'm thinking that they should be related, and most of the time be > > proper subsets of each other in terms of what changesets are in them. > > This gives us a degree of exactness you don't get when changesets are > > re-created frpm patches. Assuming we can do it or even agree to it. > > > > > The immediate problem I see is that OpenJDK6 is based on a version of > OpenJDK7 not represented in Mercurial. Only b24 and on are, and I > believe OpenJDK6 was forked prior to this. > > > >> > >>> but hotspot is somewhat special, and the express model I support, so... > >>> > >>> My suggestions... > >>> * Ignore hsx/hsx14, it's a drop not a development tree > >> > >> What??? I don't believe any discussions around HSX ever being about it > >> being just a drop. It's meant to be a stability branch of hs14 for > >> use in OpenJDK6 and Sun's JDK6 releases. If it was a drop, why do a > >> forest at all and not just update OpenJDK6? > > > > My definition of 'drop' here was that it is not intended to be a > > two-way open street as I understood the purpose. > > A simple source tarball could have worked, but since there was always > > a chance of last minute hs14 changes, a repository makes things easier, > > granted it sounds like it was updated a little slowly with the last few > > changes. > > My point in the comment is that, as I understand it, hs14 is for all > > intents and purposes, done. > > Maybe I have that wrong, but my assumption is that the team is and has > > moved on to the next hotspot express release, and hs14 is no longer > > a priority. > > > My understanding is that while development for 7 continued to hs15 and > hs166 in the public jdk7/hotspot repositories, a fork was silently > created inside Sun of hs14 for the 6 update releases. This is what > has now finally been published as hsx. The fork came as a shock to > me, and it would have been a whole lot better if it had been created > in public to begin with. Thus, my understanding is that hsx will > continue to evolve while a version of hs14 is needed for the 6 > updates. > > > > > >> > >>> * Decide to make the jdk6 and jdk7 repositories 'related' > >> > >> Impossible, unless I misunderstand what you mean by 'related'. > > > > Related to me means that both repositories have the same "changeset 0". > > What I am suggesting is that occasionally, after a sync, the jdk6 repo would > > be > > a proper subset of the jdk7 repo. > > > > > Would be nice, but see my comment about b24 above. > > > >> > >>> * Tag the rev in the jdk7/hotspot repo with a name jdk6-b17, the > >>> rev that matches what is in the hsx14 repo > >> > >> Again there is no hs14b11...hs14b16 in the public HotSpot repository. > > > > Actually I think there is, we just are not recording it in the changeset > > tags. > > > No there isn't. We wouldn't have made a fuss for three months about > it if there was :) > > > > > >> That's what sparked the whole discussion that lead to HSX in the first > >> place. Sun took HotSpot 14 'underground' and out of the public eye as > >> regards further stability work. With hsx, we finally seem to have > >> reversed this process by the release of hs14b11...hs14b16 and I'd > >> expect to see further releases appear there too. > > > > I'm just not sure you will be getting what you are expecting with this, > > again, I thought hsx14 was a done deal for the most part. > > > > > Nothing would surprise me at this stage. To be honest, I'm just > getting a little sick and tired of all these forks, especially when > (to the outside world) many seem unnecessary. With IcedTea, we > deliberately went down a more difficult path of patching the upstream > source and trying to contribute the patches upstream rather than just > forking. This was done for the good of the community. What Sun did > with hs14 seems to go against the entire purpose of the OpenJDK > project and I'd like to assume it was just a mistake. > > Even when JDK7 is released, I don't see 6 disappearing overnight. By > that time, I think we want to be in a situation where OpenJDK6 is an > open-source version of what Sun shipped as the last 6 update release > (well minus the plugin but that's a whole other story). There's no > real reason for this not to be the case AFAICS except the need for > time and effort to get everything out in the open and into OpenJDK6. > > > >> > >>> * Toss the existing jdk6/hotspot repo and replace it with a repo > >>> created with: > >>> hg clone -r jdk6-b17 http://hg.openjdk.java.net/jdk7/hotspot > >>> jdk6/hotspot > >>> > >> > >> I think the only options are to pull in changeset 0 from hsx to rebase > >> the HotSpot repo on that, or (simpler) replace it with a clone of hsx. > >> The former would preserve the commit history and would be more useful > >> over time IMO. > > > > I'm very confused now, I think we just said the same thing, or something > > extremely similar. > > > > > We're saying the same, except I'm talking about using hsx while you're > talking about using jdk7/hotspot. The latter would lose us the 6 new > build drops of hs14. > > > >> > >>> Changes going into jdk6/hotspot should be rare, critical, and should > >>> eventually be pushed back into jdk7/hotspot, indeed some critical fixes > >>> may get transplanted from jdk7/hotspot to jdk6/hotspot. > >>> If at some point it's decided to upgrade jdk6/hotspot to a newer rev, > >>> so be it, easy to do. > >>> > >> > >> I think changes should just go to hsx and then feed into OpenJDK6 > >> through regular pulls, if we plan to maintain a repo. there. > > > > EXACTLY! That is what I am suggesting for OpenJDK6, just a clone. > > > > Except you say "hsx" I say "jdk7/hotspot", to me they are the same, > > or "the latest hotspot express where all the latest work is done". > > > > > Unfortunately they aren't the same. I wish they were. > > > >> > >>> And for heavens sake, start adding some hsx-* tags to the hotspot > >>> repository > >>> so we can easily clone hsx versions from the tag name, you could also use > >>> the hsx tag to hold the build number, I can help with that. > >>> > >> > >> Now this I agree on :) > > > > Good... I'll keep pushing on this then. > > > > --- > > > > Erik, > > > > Let's start looking into hsx-* tags!!! ;^) > > > > -kto > > > >> > >>> -kto > >>> > >>> > >>> > >> > >> > >> > > > > > > > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 > From gnu_andrew at member.fsf.org Tue Jun 2 12:18:18 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 2 Jun 2009 20:18:18 +0100 Subject: Hotspot shell games In-Reply-To: References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <17c6771e0905281752v5f925e7cm9390a2eac4a6d600@mail.gmail.com> <4A1F366E.9010801@sun.com> <4A1F38A2.2090505@sun.com> <17c6771e0905290456j7c3b62f8xee36460943abe374@mail.gmail.com> <4A200AEA.3050809@sun.com> <17c6771e0905301732n1b87d8b6we0efe1af83f6a794@mail.gmail.com> <4A22CD18.9020002@sun.com> <17c6771e0906021143x1abd3e6dra2ee62dfbfd5eec1@mail.gmail.com> Message-ID: <17c6771e0906021218v4178449bp2f8852fd6e7585c7@mail.gmail.com> 2009/6/2 Volker Simonis : > On 6/2/09, Andrew John Hughes wrote: >> 2009/5/31 Kelly O'Hair : >> >> > >> ?> >> ?> Andrew John Hughes wrote: >> ?>> >> ?>> 2009/5/29 Kelly O'Hair : >> ?>>> >> ?>>> (removed jdk7-dev from this discussion) >> ?>>> >> ?>>> Andrew John Hughes wrote: >> ?>>>> >> ?>>>> 2009/5/29 Erik Trimble : >> ?>>> >> ?>>> [snip] >> ?>>>>> >> ?>>>>> For now, though, we need to decide how to handle HSX vs Open6 vs. >> ?>>>>> IceTea. >> ?>>>> >> ?>>>> Simplest solution would be to just remove it from OpenJDK6 and use HSX >> ?>>>> as the upstream. ?I don't see an advantage to pulling in to OpenJDK6, >> ?>>>> given there is already a 'stable' branch of HSX. >> ?>>> >> ?>>> I would prefer to keep a hotspot repository in the openjdk6 forest, just >> ?>>> for the sake of having a buildable and complete source base. >> ?>> >> ?>> I can see the advantage, though I would guess the number of people >> ?>> doing OpenJDK6 builds is far smaller than those doing IcedTea builds >> ?>> which has been deleting the OpenJDK6 repo and replacing it for months >> ?>> now. ?If the OpenJDK6 repo is again allowed to bit-rot, then we're >> ?>> likely to have to do this again. ?We'd obviously prefer to be working >> ?>> on a common upstream rather than having effectively two communities. >> ?> >> ?> It doesn't matter to me which is being built more or less, I just want >> ?> to make sure that OpenJDK6 is complete and does build, and work. >> ?> I also want to open it up as much as possible in terms of others >> ?> pushing changes in. I'm sure we can work this out in an acceptable way >> ?> for all concerned... read on... >> ?> >> ?>> >> ?>>> I would also like to have some level of confidence as to which hotspot >> ?>>> is the default one for the openjdk6 project. >> ?>>> Let's not leave a partial jdk6 forest sitting out there. >> ?>>> >> ?>> >> ?>> My main concern is maintenance. ?If what is there is maintained >> ?>> regularly, I don't care too much either way. ?That said, I'd prefer to >> ?>> see less duplication though, and this also extends to CORBA, JAXP and >> ?>> JAXWS as Joe already mentioned. >> ?> >> ?> I agree, and I'm all in favor. But having a complete OpenJDK6 tree, >> ?> including hotspot doesn't change that, it's just a clone of a repository >> ?> that represents what we know works. >> ?> If the IcedTea team said that they tried Hotspot version 3,246 and it >> ?> worked for them and looked solid, then hey, great, push those changesets >> ?> into the openjdk6 hotspot repository. >> ?> Or we work out some other way to update it, I'm open to suggestions, >> ?> I just would like to see 'a clone' of 'a hotspot' repository available >> ?> with the openjdk6 forest of repositories. >> ?> >> >> >> My reticence is mainly because getting changes upstream has been so >> ?slow. ?That seems to be changing though. ?I agree with your feelings >> ?about OpenJDK6 being 'complete'. >> >> >> ?>> >> ?>>> To me the decision that needs to be made is whether you want the >> ?>>> openjdk6 hotspot repository (jdk6/hotspot) 'related' to the other >> ?>>> hotspot repositories, like hsx/hsx14/master is related to jdk7/hotspot. >> ?>> >> ?>> It isn't related; hsx includes several build drops that were never in >> ?>> the public HotSpot repositories and which we had to wait over three >> ?>> months for. >> ?> >> ?> When I say 'related' I'm referring to the ability to pull/push mercurial >> ?> changesets between the repositories without transplanting or reapplying >> ?> patches. And the hsx repository is related to the public repositories, >> ?> they just might not ne in sync or be proper subsets of each other at times. >> ?> >> >> >> Ok, they are related in one direction sure; hsx and jdk7/hotspot match >> ?up to hs14b10. ?But at that point, one continues up to hs14b11, and >> ?the other starts on hs15b01 up to hs16b03 (in JDK7 b59). ?We don't >> ?want hs15 or hs16 in 6 until they have proved stable enough; that's >> ?exactly why IcedTea was using a specific HotSpot 7 changeset of >> ?hs14b10 rather than tip prior to the availability of hsx. ?But the >> ?changesets needed for OpenJDK6 simply aren't in the jdk7 forest and >> ?they can't really be inserted back in the past somewhere. >> > > This was my first thought too, but after rereading Kellys mails and > rethinking the whole story I think Kelly is right and it's possible, > exactly because the repositories are related. You can think of it as > creating a new branch in the jdk7/hotspot repository at the point > where hs14 was forked off with a new head which is the tip of the > current hsx14 repo (please see my previous mail in this thread - after > all a Mercurial repo is a real tree and you don't necessarily have to > merge all the branches in the end). The only glitch is the jcheck > problem with duplicate bug ids mentioned by Kelly. > Maybe I'm not following things right. If OpenJDK6 takes a clone of hsx, then, assuming hsx is already based on HotSpot 7's tree, it will be possible to merge changesets between all three. The only one that isn't related is the current OpenJDK6 HotSpot which we can probably just remove (hardly anyone uses it anyway). What I was thinking is that he somehow wanted to put the hsx changesets back into 7, which is possible sure but they would be on top of later changes (hs15/16) which we don't want for 6. > The one thing where I however strongly agree with you is that Sun > should do the stabilization work in the open from the very beginning, > and not after the work is finished - we'll see if this will be true at > the point where HS15/HSX15 will appear in Java 6. > Thanks :) I'm taking it as a faux pas, but that won't be the case if it happens again. >> >> ?>> >> ?>>> It doesn't have to be, and there are advantages and disadvantages to >> ?>>> both approaches. >> ?>>> None of the non-hotspot repositories in the openjdk6 forest are related >> ?>>> to the jdk7 repositories, making them pretty independent from jdk7, >> ?>> >> ?>> Which is sensible, given 6 has to be stable. ?It being based off jdk7 >> ?>> is merely an issue of when things were released under the GPL, as I >> ?>> believe you or Joe have blogged about before. >> ?> >> ?> No it's more than that, the sources themselves have a relationship between >> ?> openjdk6 and openjdk7, but the repositories themselves are not related, >> ?> you cannot pull/push changesets between these repositories. >> ?> You can reapply patches and re-create new changesets that match from >> ?> one to the other, and Mercurial makes that easy, but they are not the >> ?> same changesets. >> ?> >> >> >> Tell me about it... :) Being able to do hg export/import would be easier. >> >> >> ?> I'm thinking that they should be related, and most of the time be >> ?> proper subsets of each other in terms of what changesets are in them. >> ?> This gives us a degree of exactness you don't get when changesets are >> ?> re-created frpm patches. ?Assuming we can do it or even agree to it. >> ?> >> >> >> The immediate problem I see is that OpenJDK6 is based on a version of >> ?OpenJDK7 not represented in Mercurial. ?Only b24 and on are, and I >> ?believe OpenJDK6 was forked prior to this. >> >> >> ?>> >> ?>>> but hotspot is somewhat special, and the express model I support, so... >> ?>>> >> ?>>> My suggestions... >> ?>>> ?* Ignore hsx/hsx14, it's a drop not a development tree >> ?>> >> ?>> What??? I don't believe any discussions around HSX ever being about it >> ?>> being just a drop. ?It's meant to be a stability branch of hs14 for >> ?>> use in OpenJDK6 and Sun's JDK6 releases. ?If it was a drop, why do a >> ?>> forest at all and not just update OpenJDK6? >> ?> >> ?> My definition of 'drop' here was that it is not intended to be a >> ?> two-way open street as I understood the purpose. >> ?> A simple source tarball could have worked, but since there was always >> ?> a chance of last minute hs14 changes, a repository makes things easier, >> ?> granted it sounds like it was updated a little slowly with the last few >> ?> changes. >> ?> My point in the comment is that, as I understand it, hs14 is for all >> ?> intents and purposes, done. >> ?> Maybe I have that wrong, but my assumption is that the team is and has >> ?> moved on to the next hotspot express release, and hs14 is no longer >> ?> a priority. >> >> >> My understanding is that while development for 7 continued to hs15 and >> ?hs166 in the public jdk7/hotspot repositories, a fork was silently >> ?created inside Sun of hs14 for the 6 update releases. ?This is what >> ?has now finally been published as hsx. ?The fork came as a shock to >> ?me, and it would have been a whole lot better if it had been created >> ?in public to begin with. ?Thus, my understanding is that hsx will >> ?continue to evolve while a version of hs14 is needed for the 6 >> ?updates. >> >> >> ?> >> ?>> >> ?>>> ?* Decide to make the jdk6 and jdk7 repositories 'related' >> ?>> >> ?>> Impossible, unless I misunderstand what you mean by 'related'. >> ?> >> ?> Related to me means that both repositories have the same "changeset 0". >> ?> What I am suggesting is that occasionally, after a sync, the jdk6 repo would >> ?> be >> ?> a proper subset of the jdk7 repo. >> ?> >> >> >> Would be nice, but see my comment about b24 above. >> >> >> ?>> >> ?>>> ?* Tag the rev in the jdk7/hotspot repo with a name jdk6-b17, the >> ?>>> ? rev that matches what is in the hsx14 repo >> ?>> >> ?>> Again there is no hs14b11...hs14b16 in the public HotSpot repository. >> ?> >> ?> Actually I think there is, we just are not recording it in the changeset >> ?> tags. >> >> >> No there isn't. ?We wouldn't have made a fuss for three months about >> ?it if there was :) >> >> >> ?> >> ?>> That's what sparked the whole discussion that lead to HSX in the first >> ?>> place. ?Sun took HotSpot 14 'underground' and out of the public eye as >> ?>> regards further stability work. ?With hsx, we finally seem to have >> ?>> reversed this process by the release of hs14b11...hs14b16 and I'd >> ?>> expect to see further releases appear there too. >> ?> >> ?> I'm just not sure you will be getting what you are expecting with this, >> ?> again, I thought hsx14 was a done deal for the most part. >> ?> >> >> >> Nothing would surprise me at this stage. ?To be honest, I'm just >> ?getting a little sick and tired of all these forks, especially when >> ?(to the outside world) many seem unnecessary. ?With IcedTea, we >> ?deliberately went down a more difficult path of patching the upstream >> ?source and trying to contribute the patches upstream rather than just >> ?forking. ?This was done for the good of the community. ?What Sun did >> ?with hs14 seems to go against the entire purpose of the OpenJDK >> ?project and I'd like to assume it was just a mistake. >> >> ?Even when JDK7 is released, I don't see 6 disappearing overnight. ?By >> ?that time, I think we want to be in a situation where OpenJDK6 is an >> ?open-source version of what Sun shipped as the last 6 update release >> ?(well minus the plugin but that's a whole other story). ?There's no >> ?real reason for this not to be the case AFAICS except the need for >> ?time and effort to get everything out in the open and into OpenJDK6. >> >> >> ?>> >> ?>>> ?* Toss the existing jdk6/hotspot repo and replace it with a repo >> ?>>> ? created with: >> ?>>> ? ? ? hg clone -r jdk6-b17 http://hg.openjdk.java.net/jdk7/hotspot >> ?>>> jdk6/hotspot >> ?>>> >> ?>> >> ?>> I think the only options are to pull in changeset 0 from hsx to rebase >> ?>> the HotSpot repo on that, or (simpler) replace it with a clone of hsx. >> ?>> ?The former would preserve the commit history and would be more useful >> ?>> over time IMO. >> ?> >> ?> I'm very confused now, I think we just said the same thing, or something >> ?> extremely similar. >> ?> >> >> >> We're saying the same, except I'm talking about using hsx while you're >> ?talking about using jdk7/hotspot. ?The latter would lose us the 6 new >> ?build drops of hs14. >> >> >> ?>> >> ?>>> Changes going into jdk6/hotspot should be rare, critical, and should >> ?>>> eventually be pushed back into jdk7/hotspot, indeed some critical fixes >> ?>>> may get transplanted from jdk7/hotspot to jdk6/hotspot. >> ?>>> If at some point it's decided to upgrade jdk6/hotspot to a newer rev, >> ?>>> so be it, easy to do. >> ?>>> >> ?>> >> ?>> I think changes should just go to hsx and then feed into OpenJDK6 >> ?>> through regular pulls, if we plan to maintain a repo. there. >> ?> >> ?> EXACTLY! That is what I am suggesting for OpenJDK6, just a clone. >> ?> >> ?> Except you say "hsx" I say "jdk7/hotspot", to me they are the same, >> ?> or "the latest hotspot express where all the latest work is done". >> ?> >> >> >> Unfortunately they aren't the same. ?I wish they were. >> >> >> ?>> >> ?>>> And for heavens sake, start adding some hsx-* tags to the hotspot >> ?>>> repository >> ?>>> so we can easily clone hsx versions from the tag name, you could also use >> ?>>> the hsx tag to hold the build number, I can help with that. >> ?>>> >> ?>> >> ?>> Now this I agree on :) >> ?> >> ?> Good... ?I'll keep pushing on this then. >> ?> >> ?> --- >> ?> >> ?> Erik, >> ?> >> ?> Let's start looking into hsx-* tags!!! ;^) >> ?> >> ?> -kto >> ?> >> ?>> >> ?>>> -kto >> ?>>> >> ?>>> >> ?>>> >> ?>> >> ?>> >> ?>> >> ?> >> >> >> >> >> -- >> ?Andrew :-) >> >> ?Free Java Software Engineer >> ?Red Hat, Inc. (http://www.redhat.com) >> >> ?Support Free Java! >> ?Contribute to GNU Classpath and the OpenJDK >> ?http://www.gnu.org/software/classpath >> ?http://openjdk.java.net >> >> ?PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> ?Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >> > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From volker.simonis at gmail.com Tue Jun 2 12:40:38 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 2 Jun 2009 21:40:38 +0200 Subject: Hotspot shell games In-Reply-To: <17c6771e0906021218v4178449bp2f8852fd6e7585c7@mail.gmail.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A1F366E.9010801@sun.com> <4A1F38A2.2090505@sun.com> <17c6771e0905290456j7c3b62f8xee36460943abe374@mail.gmail.com> <4A200AEA.3050809@sun.com> <17c6771e0905301732n1b87d8b6we0efe1af83f6a794@mail.gmail.com> <4A22CD18.9020002@sun.com> <17c6771e0906021143x1abd3e6dra2ee62dfbfd5eec1@mail.gmail.com> <17c6771e0906021218v4178449bp2f8852fd6e7585c7@mail.gmail.com> Message-ID: On 6/2/09, Andrew John Hughes wrote: > 2009/6/2 Volker Simonis : > > > On 6/2/09, Andrew John Hughes wrote: > >> 2009/5/31 Kelly O'Hair : > >> > >> > > >> > > >> > Andrew John Hughes wrote: > >> >> > >> >> 2009/5/29 Kelly O'Hair : > >> >>> > >> >>> (removed jdk7-dev from this discussion) > >> >>> > >> >>> Andrew John Hughes wrote: > >> >>>> > >> >>>> 2009/5/29 Erik Trimble : > >> >>> > >> >>> [snip] > >> >>>>> > >> >>>>> For now, though, we need to decide how to handle HSX vs Open6 vs. > >> >>>>> IceTea. > >> >>>> > >> >>>> Simplest solution would be to just remove it from OpenJDK6 and use HSX > >> >>>> as the upstream. I don't see an advantage to pulling in to OpenJDK6, > >> >>>> given there is already a 'stable' branch of HSX. > >> >>> > >> >>> I would prefer to keep a hotspot repository in the openjdk6 forest, just > >> >>> for the sake of having a buildable and complete source base. > >> >> > >> >> I can see the advantage, though I would guess the number of people > >> >> doing OpenJDK6 builds is far smaller than those doing IcedTea builds > >> >> which has been deleting the OpenJDK6 repo and replacing it for months > >> >> now. If the OpenJDK6 repo is again allowed to bit-rot, then we're > >> >> likely to have to do this again. We'd obviously prefer to be working > >> >> on a common upstream rather than having effectively two communities. > >> > > >> > It doesn't matter to me which is being built more or less, I just want > >> > to make sure that OpenJDK6 is complete and does build, and work. > >> > I also want to open it up as much as possible in terms of others > >> > pushing changes in. I'm sure we can work this out in an acceptable way > >> > for all concerned... read on... > >> > > >> >> > >> >>> I would also like to have some level of confidence as to which hotspot > >> >>> is the default one for the openjdk6 project. > >> >>> Let's not leave a partial jdk6 forest sitting out there. > >> >>> > >> >> > >> >> My main concern is maintenance. If what is there is maintained > >> >> regularly, I don't care too much either way. That said, I'd prefer to > >> >> see less duplication though, and this also extends to CORBA, JAXP and > >> >> JAXWS as Joe already mentioned. > >> > > >> > I agree, and I'm all in favor. But having a complete OpenJDK6 tree, > >> > including hotspot doesn't change that, it's just a clone of a repository > >> > that represents what we know works. > >> > If the IcedTea team said that they tried Hotspot version 3,246 and it > >> > worked for them and looked solid, then hey, great, push those changesets > >> > into the openjdk6 hotspot repository. > >> > Or we work out some other way to update it, I'm open to suggestions, > >> > I just would like to see 'a clone' of 'a hotspot' repository available > >> > with the openjdk6 forest of repositories. > >> > > >> > >> > >> My reticence is mainly because getting changes upstream has been so > >> slow. That seems to be changing though. I agree with your feelings > >> about OpenJDK6 being 'complete'. > >> > >> > >> >> > >> >>> To me the decision that needs to be made is whether you want the > >> >>> openjdk6 hotspot repository (jdk6/hotspot) 'related' to the other > >> >>> hotspot repositories, like hsx/hsx14/master is related to jdk7/hotspot. > >> >> > >> >> It isn't related; hsx includes several build drops that were never in > >> >> the public HotSpot repositories and which we had to wait over three > >> >> months for. > >> > > >> > When I say 'related' I'm referring to the ability to pull/push mercurial > >> > changesets between the repositories without transplanting or reapplying > >> > patches. And the hsx repository is related to the public repositories, > >> > they just might not ne in sync or be proper subsets of each other at times. > >> > > >> > >> > >> Ok, they are related in one direction sure; hsx and jdk7/hotspot match > >> up to hs14b10. But at that point, one continues up to hs14b11, and > >> the other starts on hs15b01 up to hs16b03 (in JDK7 b59). We don't > >> want hs15 or hs16 in 6 until they have proved stable enough; that's > >> exactly why IcedTea was using a specific HotSpot 7 changeset of > >> hs14b10 rather than tip prior to the availability of hsx. But the > >> changesets needed for OpenJDK6 simply aren't in the jdk7 forest and > >> they can't really be inserted back in the past somewhere. > >> > > > > This was my first thought too, but after rereading Kellys mails and > > rethinking the whole story I think Kelly is right and it's possible, > > exactly because the repositories are related. You can think of it as > > creating a new branch in the jdk7/hotspot repository at the point > > where hs14 was forked off with a new head which is the tip of the > > current hsx14 repo (please see my previous mail in this thread - after > > all a Mercurial repo is a real tree and you don't necessarily have to > > merge all the branches in the end). The only glitch is the jcheck > > problem with duplicate bug ids mentioned by Kelly. > > > > > Maybe I'm not following things right. If OpenJDK6 takes a clone of > hsx, then, assuming hsx is already based on HotSpot 7's tree, it will > be possible to merge changesets between all three. The only one that > isn't related is the current OpenJDK6 HotSpot which we can probably > just remove (hardly anyone uses it anyway). What I was thinking is > that he somehow wanted to put the hsx changesets back into 7, which is > possible sure but they would be on top of later changes (hs15/16) > which we don't want for 6. > Yes, that's what he wanted and no, they would not sit on top of hs15/16 - the repo would look like this (you probably want to look at this with a fixed size font such that it makes sense): -> hs14b01->..->hs14b10->hs15b01->..->hs16b01->.. (default branch) \ (initial hsx14 clone) \ \->hs14b10->hs14b11->..->hs14b17->.. (HSX14 branch) The HSX14 branch can be easily created in the jdk7/hotspot repo by syncing to "hs14b10" and pulling from the HSX14 repo. You just create a new head in jdk7/hotspot - that's all... > > > The one thing where I however strongly agree with you is that Sun > > should do the stabilization work in the open from the very beginning, > > and not after the work is finished - we'll see if this will be true at > > the point where HS15/HSX15 will appear in Java 6. > > > > > Thanks :) > I'm taking it as a faux pas, but that won't be the case if it happens again. > > > >> > >> >> > >> >>> It doesn't have to be, and there are advantages and disadvantages to > >> >>> both approaches. > >> >>> None of the non-hotspot repositories in the openjdk6 forest are related > >> >>> to the jdk7 repositories, making them pretty independent from jdk7, > >> >> > >> >> Which is sensible, given 6 has to be stable. It being based off jdk7 > >> >> is merely an issue of when things were released under the GPL, as I > >> >> believe you or Joe have blogged about before. > >> > > >> > No it's more than that, the sources themselves have a relationship between > >> > openjdk6 and openjdk7, but the repositories themselves are not related, > >> > you cannot pull/push changesets between these repositories. > >> > You can reapply patches and re-create new changesets that match from > >> > one to the other, and Mercurial makes that easy, but they are not the > >> > same changesets. > >> > > >> > >> > >> Tell me about it... :) Being able to do hg export/import would be easier. > >> > >> > >> > I'm thinking that they should be related, and most of the time be > >> > proper subsets of each other in terms of what changesets are in them. > >> > This gives us a degree of exactness you don't get when changesets are > >> > re-created frpm patches. Assuming we can do it or even agree to it. > >> > > >> > >> > >> The immediate problem I see is that OpenJDK6 is based on a version of > >> OpenJDK7 not represented in Mercurial. Only b24 and on are, and I > >> believe OpenJDK6 was forked prior to this. > >> > >> > >> >> > >> >>> but hotspot is somewhat special, and the express model I support, so... > >> >>> > >> >>> My suggestions... > >> >>> * Ignore hsx/hsx14, it's a drop not a development tree > >> >> > >> >> What??? I don't believe any discussions around HSX ever being about it > >> >> being just a drop. It's meant to be a stability branch of hs14 for > >> >> use in OpenJDK6 and Sun's JDK6 releases. If it was a drop, why do a > >> >> forest at all and not just update OpenJDK6? > >> > > >> > My definition of 'drop' here was that it is not intended to be a > >> > two-way open street as I understood the purpose. > >> > A simple source tarball could have worked, but since there was always > >> > a chance of last minute hs14 changes, a repository makes things easier, > >> > granted it sounds like it was updated a little slowly with the last few > >> > changes. > >> > My point in the comment is that, as I understand it, hs14 is for all > >> > intents and purposes, done. > >> > Maybe I have that wrong, but my assumption is that the team is and has > >> > moved on to the next hotspot express release, and hs14 is no longer > >> > a priority. > >> > >> > >> My understanding is that while development for 7 continued to hs15 and > >> hs166 in the public jdk7/hotspot repositories, a fork was silently > >> created inside Sun of hs14 for the 6 update releases. This is what > >> has now finally been published as hsx. The fork came as a shock to > >> me, and it would have been a whole lot better if it had been created > >> in public to begin with. Thus, my understanding is that hsx will > >> continue to evolve while a version of hs14 is needed for the 6 > >> updates. > >> > >> > >> > > >> >> > >> >>> * Decide to make the jdk6 and jdk7 repositories 'related' > >> >> > >> >> Impossible, unless I misunderstand what you mean by 'related'. > >> > > >> > Related to me means that both repositories have the same "changeset 0". > >> > What I am suggesting is that occasionally, after a sync, the jdk6 repo would > >> > be > >> > a proper subset of the jdk7 repo. > >> > > >> > >> > >> Would be nice, but see my comment about b24 above. > >> > >> > >> >> > >> >>> * Tag the rev in the jdk7/hotspot repo with a name jdk6-b17, the > >> >>> rev that matches what is in the hsx14 repo > >> >> > >> >> Again there is no hs14b11...hs14b16 in the public HotSpot repository. > >> > > >> > Actually I think there is, we just are not recording it in the changeset > >> > tags. > >> > >> > >> No there isn't. We wouldn't have made a fuss for three months about > >> it if there was :) > >> > >> > >> > > >> >> That's what sparked the whole discussion that lead to HSX in the first > >> >> place. Sun took HotSpot 14 'underground' and out of the public eye as > >> >> regards further stability work. With hsx, we finally seem to have > >> >> reversed this process by the release of hs14b11...hs14b16 and I'd > >> >> expect to see further releases appear there too. > >> > > >> > I'm just not sure you will be getting what you are expecting with this, > >> > again, I thought hsx14 was a done deal for the most part. > >> > > >> > >> > >> Nothing would surprise me at this stage. To be honest, I'm just > >> getting a little sick and tired of all these forks, especially when > >> (to the outside world) many seem unnecessary. With IcedTea, we > >> deliberately went down a more difficult path of patching the upstream > >> source and trying to contribute the patches upstream rather than just > >> forking. This was done for the good of the community. What Sun did > >> with hs14 seems to go against the entire purpose of the OpenJDK > >> project and I'd like to assume it was just a mistake. > >> > >> Even when JDK7 is released, I don't see 6 disappearing overnight. By > >> that time, I think we want to be in a situation where OpenJDK6 is an > >> open-source version of what Sun shipped as the last 6 update release > >> (well minus the plugin but that's a whole other story). There's no > >> real reason for this not to be the case AFAICS except the need for > >> time and effort to get everything out in the open and into OpenJDK6. > >> > >> > >> >> > >> >>> * Toss the existing jdk6/hotspot repo and replace it with a repo > >> >>> created with: > >> >>> hg clone -r jdk6-b17 http://hg.openjdk.java.net/jdk7/hotspot > >> >>> jdk6/hotspot > >> >>> > >> >> > >> >> I think the only options are to pull in changeset 0 from hsx to rebase > >> >> the HotSpot repo on that, or (simpler) replace it with a clone of hsx. > >> >> The former would preserve the commit history and would be more useful > >> >> over time IMO. > >> > > >> > I'm very confused now, I think we just said the same thing, or something > >> > extremely similar. > >> > > >> > >> > >> We're saying the same, except I'm talking about using hsx while you're > >> talking about using jdk7/hotspot. The latter would lose us the 6 new > >> build drops of hs14. > >> > >> > >> >> > >> >>> Changes going into jdk6/hotspot should be rare, critical, and should > >> >>> eventually be pushed back into jdk7/hotspot, indeed some critical fixes > >> >>> may get transplanted from jdk7/hotspot to jdk6/hotspot. > >> >>> If at some point it's decided to upgrade jdk6/hotspot to a newer rev, > >> >>> so be it, easy to do. > >> >>> > >> >> > >> >> I think changes should just go to hsx and then feed into OpenJDK6 > >> >> through regular pulls, if we plan to maintain a repo. there. > >> > > >> > EXACTLY! That is what I am suggesting for OpenJDK6, just a clone. > >> > > >> > Except you say "hsx" I say "jdk7/hotspot", to me they are the same, > >> > or "the latest hotspot express where all the latest work is done". > >> > > >> > >> > >> Unfortunately they aren't the same. I wish they were. > >> > >> > >> >> > >> >>> And for heavens sake, start adding some hsx-* tags to the hotspot > >> >>> repository > >> >>> so we can easily clone hsx versions from the tag name, you could also use > >> >>> the hsx tag to hold the build number, I can help with that. > >> >>> > >> >> > >> >> Now this I agree on :) > >> > > >> > Good... I'll keep pushing on this then. > >> > > >> > --- > >> > > >> > Erik, > >> > > >> > Let's start looking into hsx-* tags!!! ;^) > >> > > >> > -kto > >> > > >> >> > >> >>> -kto > >> >>> > >> >>> > >> >>> > >> >> > >> >> > >> >> > >> > > >> > >> > >> > >> > >> -- > >> Andrew :-) > >> > >> Free Java Software Engineer > >> Red Hat, Inc. (http://www.redhat.com) > >> > >> Support Free Java! > >> Contribute to GNU Classpath and the OpenJDK > >> http://www.gnu.org/software/classpath > >> http://openjdk.java.net > >> > >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 > >> > > > > > > > -- > > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20090602/424e2a66/attachment.html From mark at klomp.org Thu Jun 4 06:19:58 2009 From: mark at klomp.org (Mark Wielaard) Date: Thu, 04 Jun 2009 15:19:58 +0200 Subject: Setting public TestEnv defaults for net/nio tests needing hosts In-Reply-To: <1226790321.3805.12.camel@dijkstra.wildebeest.org> References: <1226790321.3805.12.camel@dijkstra.wildebeest.org> Message-ID: <1244121598.3565.21.camel@hermans.wildebeest.org> Hi, On Sun, 2008-11-16 at 00:05 +0100, Mark Wielaard wrote: > I made sure all needed services are enabled on > icedtea.classpath.org/developer.classpath.org and set those as defaults > in TestEnv for the net/nio tests that need to contact hosts. Using > icedtea for remote_host and developer for far_host is somewhat > arbitrary, but at least these hosts are public. > > I also made sure the cname.sh test uses the far_host to do its tests > instead of a hardcoded one. And I changed the SocketChannel LocalAddress > and Shutdown tests to use the echo service. Since the echo service > already has to be enabled for other tests and I didn't want to open up a > telnet port. > [...] > All the tests using TestEnv in make check-jdk target now PASS for me. > > Note that TestEnv hasn't been forward ported from jdk6 to jdk7. So I > haven't yet pushed this patch upstream to the jdk7 net/nio lists. The jdk6 and jdk7 environments are still somewhat dissimilar, but thanks to Andrew Hughes the patches have been ported to make sure they also work on jdk7 out of the box by default using just public hosts without the need to change anything in your test environment locally. Attached is the patch against jdk7. I also filed (the jdk6 version) in bugzilla so it doesn't get forgotten: https://bugs.openjdk.java.net/show_bug.cgi?id=100066 Thanks, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea-testenv.patch Type: text/x-patch Size: 3185 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20090604/b81d04af/attachment.bin From Alan.Bateman at Sun.COM Thu Jun 4 09:58:20 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 04 Jun 2009 17:58:20 +0100 Subject: Setting public TestEnv defaults for net/nio tests needing hosts In-Reply-To: <1244121598.3565.21.camel@hermans.wildebeest.org> References: <1226790321.3805.12.camel@dijkstra.wildebeest.org> <1244121598.3565.21.camel@hermans.wildebeest.org> Message-ID: <4A27FD2C.7030804@sun.com> Mark Wielaard wrote: > : > The jdk6 and jdk7 environments are still somewhat dissimilar, but thanks > to Andrew Hughes the patches have been ported to make sure they also > work on jdk7 out of the box by default using just public hosts without > the need to change anything in your test environment locally. Attached > is the patch against jdk7. > > I also filed (the jdk6 version) in bugzilla so it doesn't get forgotten: > https://bugs.openjdk.java.net/show_bug.cgi?id=100066 > > Thanks, > > Mark > It's been on my list to forward-port the TestEnv and test updates to jdk7 (just haven't got to it yet). The idea with that was that jtreg would be run with a properties file that listed the hosts that the tests depend on (eg: jtreg -e JTREG_TESTENV=openjdk-hosts.properties). We (meaning Joe and I) kinda hoped that would be preferable to patching TestEnv but maybe this isn't the case. Changing these tests to not depend on the telnet port is a good idea as it is hard to find systems with that legacy service enabled. Changing the defaults to hosts outside of Sun is reasonable in principle but this is going to cause disruption for our test teams when running on test systems that will not be able to connect to these systems. I need to check into this and also to see if openjdk.java.net systems could be used, or maybe just re-visit these tests to not depend on other hosts. -Alan. From mark at klomp.org Thu Jun 4 10:27:50 2009 From: mark at klomp.org (Mark Wielaard) Date: Thu, 04 Jun 2009 19:27:50 +0200 Subject: Setting public TestEnv defaults for net/nio tests needing hosts In-Reply-To: <4A27FD2C.7030804@sun.com> References: <1226790321.3805.12.camel@dijkstra.wildebeest.org> <1244121598.3565.21.camel@hermans.wildebeest.org> <4A27FD2C.7030804@sun.com> Message-ID: <1244136471.3565.29.camel@hermans.wildebeest.org> Hi Alan, On Thu, 2009-06-04 at 17:58 +0100, Alan Bateman wrote: > It's been on my list to forward-port the TestEnv and test updates to > jdk7 (just haven't got to it yet). Thanks. > The idea with that was that jtreg > would be run with a properties file that listed the hosts that the tests > depend on (eg: jtreg -e JTREG_TESTENV=openjdk-hosts.properties). We > (meaning Joe and I) kinda hoped that would be preferable to patching > TestEnv but maybe this isn't the case. That is preferable. That is actually why I made the change. So that no editing or setting or properties was needed by default, unless you needed a set different from the public defaults. > Changing these tests to not > depend on the telnet port is a good idea as it is hard to find systems > with that legacy service enabled. Changing the defaults to hosts outside > of Sun is reasonable in principle but this is going to cause disruption > for our test teams when running on test systems that will not be able to > connect to these systems. I need to check into this and also to see if > openjdk.java.net systems could be used, or maybe just re-visit these > tests to not depend on other hosts. Yes, making this as easy as possible for anybody running the tests, so in principle you don't have to changed or edited anything was the goal. So the real changes are just to use one standard (echo) port to make it easier to switch hosts. Make cname.sh not use a hardcoded host. And then set the defaults so that they work for everybody out of the box against a set of publicly available machines. Then only people needing to do tests against non-public machines have to change any settings. Cheers, Mark From volker.simonis at gmail.com Fri Jun 5 09:54:55 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 5 Jun 2009 18:54:55 +0200 Subject: Sync'd HSX14 with latest shipping Sun HSX bits... In-Reply-To: <4A20AC97.9050607@sun.com> References: <4A20AC97.9050607@sun.com> Message-ID: Hi Erik, just a small question: what's with HS14.0b17 and HS14.1.b01 which is in 6u15-ea-b01. Will they eventually appear in the HSX14 repos? Regards, Volker On 5/30/09, Erik Trimble wrote: > OK, I just sync'd the HSX14 repos with the final source for Hotspot 14 as > shipped in Sun JDK 6 Update 14. > > -- > Erik Trimble > Java System Support > Mailstop: usca22-123 > Phone: x17195 > Santa Clara, CA > Timezone: US/Pacific (GMT-0800) > > From Erik.Trimble at Sun.COM Fri Jun 5 10:29:16 2009 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Fri, 05 Jun 2009 10:29:16 -0700 Subject: Sync'd HSX14 with latest shipping Sun HSX bits... In-Reply-To: References: <4A20AC97.9050607@sun.com> Message-ID: <4A2955EC.8090806@sun.com> Volker Simonis wrote: > Hi Erik, > > just a small question: what's with HS14.0b17 and HS14.1.b01 which is > in 6u15-ea-b01. Will they eventually appear in the HSX14 repos? > > Regards, > Volker > > My understanding is that 6u15 will be a security release, and thus, I don't think HSX14.1 source will be available publicly until AFTER it ships. HSX14.0b17 was the starting point for our Java-For-Business 6u14 release, which won't be made public. Most (if not all) of those fixes will eventually be made part of an HSX14 release and made public, but when I can't say. We're still debating as to which HSX will ship with 6u16, which is the next general 6Update release. In any case, I would expect (but don't hold me to it) that HSX14.2 will contain all fixes in both J4B 6u14 and 6u15 hotspot. I don't know when we'll be releasing 14.2, though. My understanding of how we do open-sourcing of 6Update releases: "Normal" 6Update releases (which tend to be EVEN numbers): this will be worked on in public, with community submissions; when completed, the repo will be frozen and the HSX version shipped. "Performance" releases (generally EVEN numbers with "p" appended): additional performance-related enhancements are added, not all of which are completely stable. Often, this is where we take the latest Open7 Hotspot and try to stabilize it enough for 6Update. If we're not doing that, then we're back-porting certain performance-specific enhancements. In most cases, these releases are NEVER made public, as they tend to be for benchmark submissions; also, they tend to be point-in-time drops of the code, and we don't do much stabilization work on them, so they're not really Super-Stability-Guarantied. "Security" releases (generally ODD numbers): are based off the preceding Normal release, and encompass known security bugfixes. We tend to work on these releases in private (with community submissions welcome), and then release the source upon shipment of the finished release. "Java-for-Business" releases (which tend to be EVEN numbers with "-rev" added): like Security releases, they are based on a certain Normal release. However, we fix certain issues that companies with the appropriate support contracts want. J4B release sources are NEVER made public, and we tend to distribute the binaries only to contract customers. Many of these fixes may make their way into a Normal release at some point, but some won't. The reason behind this is that some of these fixes aren't generally applicable for a wide audience, and indeed, are sometimes detrimental for general use. One-offs: For certain customers, we'll fix individual issues, in which case they get a custom built JDK specifically for that customer. These obviously aren't public, and not available to anyone except the requesting customer. Even more than J4B releases, it is unlikely that fixes in such custom builds will be rolled into a "mainstream" release, as they tend to be highly specific issues. Please don't take this to be an Official Declaration; this is just my understanding so far, and given the very fluid nature of how the 6Open stuff is being handled, I could very well be wrong. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA From martinrb at google.com Sat Jun 6 15:59:24 2009 From: martinrb at google.com (Martin Buchholz) Date: Sat, 6 Jun 2009 15:59:24 -0700 Subject: Hotspot shell games In-Reply-To: References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A1F38A2.2090505@sun.com> <17c6771e0905290456j7c3b62f8xee36460943abe374@mail.gmail.com> <4A200AEA.3050809@sun.com> <17c6771e0905301732n1b87d8b6we0efe1af83f6a794@mail.gmail.com> <4A22CD18.9020002@sun.com> <17c6771e0906021143x1abd3e6dra2ee62dfbfd5eec1@mail.gmail.com> <17c6771e0906021218v4178449bp2f8852fd6e7585c7@mail.gmail.com> Message-ID: <1ccfd1c10906061559m136cdaffu942ad4532cd34a90@mail.gmail.com> There's a cultural reason for keeping only one "head" per repo, namely that the prior source code control system "Teamware" was used this way at Sun. I expect also in future this will be the case; "branch" will be spelled "clone". Martin On Tue, Jun 2, 2009 at 12:40, Volker Simonis wrote: > > Yes, that's what he wanted and no, they would not sit on top of hs15/16 - > the repo would look like this (you probably want to look at this with a > fixed size font such that it makes sense): > > -> hs14b01->..->hs14b10->hs15b01->..->hs16b01->.. (default branch) > \ > (initial hsx14 clone) > \ > \->hs14b10->hs14b11->..->hs14b17->.. (HSX14 branch) > > The HSX14 branch can be easily created in the jdk7/hotspot repo by syncing > to "hs14b10" and pulling from the HSX14 repo. You just create a new head in > jdk7/hotspot - that's all... > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20090606/cd63fb79/attachment.html From mark at klomp.org Mon Jun 8 08:51:45 2009 From: mark at klomp.org (Mark Wielaard) Date: Mon, 08 Jun 2009 17:51:45 +0200 Subject: OpenJDK and the new plugin In-Reply-To: <17c6771e0901162003h184176d4j3da7f934a1844288@mail.gmail.com> References: <49712581.8070000@sun.com> <17c6771e0901162003h184176d4j3da7f934a1844288@mail.gmail.com> Message-ID: <1244476305.3661.167.camel@hermans.wildebeest.org> Hi Joe, On Sat, 2009-01-17 at 04:03 +0000, Andrew John Hughes wrote: > 2009/1/17 Joseph D. Darcy : > > I'm happy to announce that within the next few months as part of OpenJDK, we > > are Sun are committed to open sourcing our Java Web Start implementation and > > the new plug-in implementation for NPAPI capable browsers; those browsers > > including Firefox 3, amongst others. > > Woo! Great news! This is indeed really great! It has been a few months now. Is there already a roadmap for how and when the code will enter the repositories? Will it go into jdk6 first, or will it go through jdk7. Will it be part of the M4 milestone that has all the other 6u10 backported features? Thanks, Mark From gnu_andrew at member.fsf.org Mon Jun 8 10:04:15 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 8 Jun 2009 18:04:15 +0100 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 Message-ID: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> The following webrev: http://fuseyism.com/6781583/webrev.00/ is backported from OpenJDK7. It allows hs14 to be built using GCC 4.3 and above. Otherwise, the build fails. IcedTea has been applying an equivalent fix as three separately developed patches, two of which have been there pretty much since its inception in the summer of 2007. Ok to commit? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Mon Jun 8 10:05:14 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 8 Jun 2009 18:05:14 +0100 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> Message-ID: <17c6771e0906081005w14655c3w58d6cecee6eed013@mail.gmail.com> 2009/6/8 Andrew John Hughes : > The following webrev: > > http://fuseyism.com/6781583/webrev.00/ > > is backported from OpenJDK7. ?It allows hs14 to be built using GCC 4.3 > and above. ?Otherwise, the build fails. ?IcedTea has been applying an > equivalent fix as three separately developed patches, two of which > have been there pretty much since its inception in the summer of 2007. > > Ok to commit? > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > It's in the webrev, but to be explicit: this is for the new hs14 tree. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Kelly.Ohair at Sun.COM Mon Jun 8 12:49:33 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 08 Jun 2009 12:49:33 -0700 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> Message-ID: <4A2D6B4D.4020104@sun.com> Someone from the hotspot team really needs to review this, but my observations on these changes: * Changing the typedef for jlong seemed really risky to me, but I investigated it more and I'm pretty sure this is the right change, and forces it to match the public definition from jni.h/jni_md.h. So it looks right. * The realpath() changes in src/os/linux/vm/os_linux.cpp seem to change the definition of this method when an error occurs, the control flow has changed, and I'm not exactly sure what the return value is when realpath() fails. I doubt realpath() fails very often here, but won't the buf[] array get some arbitrary directory when realpath() fails? Is that ok? That jvm_path() is a bizarre little method. :^{ * Changing the _lineno field in src/share/vm/utilities/vmError.hpp from an int to a size_t might seem right type wise, but sure seems like a waste of space. Does a lineno really need to use up 64bits of space? * The *PTR* changes look right. * The addition of an unused local variable like in src/share/vm/utilities/ostream.cpp to avoid a warning message just seems wrong to me, and will likely create a new warning message about an unused local variable. Seems like I've had this discussion before. I prefer an explicit (void) cast on a function call whose return value is not needed and I am frustrated with GCC's inability to understand what that (void) cast means. I really like the idea of using -Werror and not allowing warnings, but at times like this I have to wonder if we should just remove the -Werror unless we know that specific version of GCC is < 4.3. But like I said, a 'real' hotspot developer should probably review this. ;^) -kto Andrew John Hughes wrote: > The following webrev: > > http://fuseyism.com/6781583/webrev.00/ > > is backported from OpenJDK7. It allows hs14 to be built using GCC 4.3 > and above. Otherwise, the build fails. IcedTea has been applying an > equivalent fix as three separately developed patches, two of which > have been there pretty much since its inception in the summer of 2007. > > Ok to commit? From Joe.Darcy at Sun.COM Mon Jun 8 13:02:15 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Mon, 08 Jun 2009 13:02:15 -0700 Subject: OpenJDK and the new plugin In-Reply-To: <1244476305.3661.167.camel@hermans.wildebeest.org> References: <49712581.8070000@sun.com> <17c6771e0901162003h184176d4j3da7f934a1844288@mail.gmail.com> <1244476305.3661.167.camel@hermans.wildebeest.org> Message-ID: <4A2D6E47.6080907@sun.com> Mark Wielaard wrote: > Hi Joe, > > On Sat, 2009-01-17 at 04:03 +0000, Andrew John Hughes wrote: > >> 2009/1/17 Joseph D. Darcy : >> >>> I'm happy to announce that within the next few months as part of OpenJDK, we >>> are Sun are committed to open sourcing our Java Web Start implementation and >>> the new plug-in implementation for NPAPI capable browsers; those browsers >>> including Firefox 3, amongst others. >>> >> Woo! Great news! >> > > This is indeed really great! > > It has been a few months now. Is there already a roadmap for how and > when the code will enter the repositories? Will it go into jdk6 first, > or will it go through jdk7. Will it be part of the M4 milestone that has > all the other 6u10 backported features? > > Thanks, > > Mark > > Hello Mark. Since that posting, circumstances have changed and unfortunately there is no specific time line to share for the webstart and new plug-in code being available under open source. -Joe From gnu_andrew at member.fsf.org Mon Jun 8 14:40:24 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 8 Jun 2009 22:40:24 +0100 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <4A2D6B4D.4020104@sun.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> <4A2D6B4D.4020104@sun.com> Message-ID: <17c6771e0906081440k72a2cdb6tad75653d1e7cbcce@mail.gmail.com> 2009/6/8 Kelly O'Hair : > Someone from the hotspot team really needs to review this Errr.... 4 of them already did: http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/2328d1d3f8cf I'm not the author of this patch, I just backported it from OpenJDK7 where it's been applied for over six months. I don't remember this patch being reviewed openly and I disliked having all the fixes rolled into one megafix like this. But given this had been reviewed and was in 7, it seemed better to backport this (just a matter of hg export/import) rather than trying to get each individual IcedTea patch through, especially as one of ours just turns off -Werror... (to some degree anyway) The relevant IcedTea patches are icedtea-fortify-source.patch (author: Matthias Klose), hotspot/default/icedtea-format.patch (author: me), icedtea-no-bcopy.patch (author: Matthias Klose), hotspot/default/icedtea-gcc-4.3.patch (originally part of a patch by Bernhard Rosenkraenzer according to the ChangeLog). , but my > observations on these changes: > > ?* Changing the typedef for jlong seemed really risky to me, but I > ? ?investigated it more and I'm pretty sure this is the right change, > ? ?and forces it to match the public definition from jni.h/jni_md.h. > ? ?So it looks right. > It's kind of annoying it has to be defined repeatedly for each arch. We also had to add this to Zero in IcedTea. > ?* The realpath() changes in src/os/linux/vm/os_linux.cpp seem to change > ? ?the definition of this method when an error occurs, the control > ? ?flow has changed, and I'm not exactly sure what the return value is > ? ?when realpath() fails. I doubt realpath() fails very often here, > ? ?but won't the buf[] array get some arbitrary directory when realpath() > ? ?fails? Is that ok? That jvm_path() is a bizarre little method. :^{ > In IcedTea, an unused variable is used which isn't ideal either, but at least doesn't change the semantics. > ?* Changing the _lineno field in src/share/vm/utilities/vmError.hpp > ? ?from an int to a size_t might seem right type wise, but sure seems > ? ?like a waste of space. Does a lineno really need to use up 64bits of > space? This doesn't seem to be patched in IcedTea, so I don't know the reasoning for the change. Increasing the size to 64 bits on x86_64 does seem wrong though. > > ?* The *PTR* changes look right. > Yeah, our patches are virtually identical on this :) > ?* The addition of an unused local variable like in > ? ? ?src/share/vm/utilities/ostream.cpp > ? ?to avoid a warning message just seems wrong to me, and will likely > ? ?create a new warning message about an unused local variable. > ? ?Seems like I've had this discussion before. > ? ?I prefer an explicit (void) cast on a function call whose return > ? ?value is not needed and I am frustrated with GCC's inability to > ? ?understand what that (void) cast means. > ? ?I really like the idea of using -Werror and not allowing warnings, > ? ?but at times like this I have to wonder if we should just remove > ? ?the -Werror unless we know that specific version of GCC is < 4.3. > IcedTea does the same for this and the one above, but uses __attribute__(unused) to avoid the warning. > But like I said, a 'real' hotspot developer should probably review this. ;^) > > -kto > > > Andrew John Hughes wrote: >> >> The following webrev: >> >> http://fuseyism.com/6781583/webrev.00/ >> >> is backported from OpenJDK7. ?It allows hs14 to be built using GCC 4.3 >> and above. ?Otherwise, the build fails. ?IcedTea has been applying an >> equivalent fix as three separately developed patches, two of which >> have been there pretty much since its inception in the summer of 2007. >> >> Ok to commit? > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Mon Jun 8 14:42:57 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 8 Jun 2009 22:42:57 +0100 Subject: OpenJDK and the new plugin In-Reply-To: <4A2D6E47.6080907@sun.com> References: <49712581.8070000@sun.com> <17c6771e0901162003h184176d4j3da7f934a1844288@mail.gmail.com> <1244476305.3661.167.camel@hermans.wildebeest.org> <4A2D6E47.6080907@sun.com> Message-ID: <17c6771e0906081442h970278fs33ddfb3715a9827d@mail.gmail.com> 2009/6/8 Joseph D. Darcy : > Mark Wielaard wrote: >> >> Hi Joe, >> >> On Sat, 2009-01-17 at 04:03 +0000, Andrew John Hughes wrote: >> >>> >>> 2009/1/17 Joseph D. Darcy : >>> >>>> >>>> I'm happy to announce that within the next few months as part of >>>> OpenJDK, we >>>> are Sun are committed to open sourcing our Java Web Start implementation >>>> and >>>> the new plug-in implementation for NPAPI capable browsers; those >>>> browsers >>>> including Firefox 3, amongst others. >>>> >>> >>> Woo! Great news! >>> >> >> This is indeed really great! >> >> It has been a few months now. Is there already a roadmap for how and >> when the code will enter the repositories? Will it go into jdk6 first, >> or will it go through jdk7. Will it be part of the M4 milestone that has >> all the other 6u10 backported features? >> >> Thanks, >> >> Mark >> >> > > Hello Mark. > > Since that posting, circumstances have changed and unfortunately there is no > specific time line to share for the webstart and new plug-in code being > available under open source. > > -Joe > We'd better keep hacking on that replacement then... -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From mark at klomp.org Mon Jun 8 15:20:28 2009 From: mark at klomp.org (Mark Wielaard) Date: Tue, 09 Jun 2009 00:20:28 +0200 Subject: OpenJDK and the new plugin In-Reply-To: <17c6771e0906081442h970278fs33ddfb3715a9827d@mail.gmail.com> References: <49712581.8070000@sun.com> <17c6771e0901162003h184176d4j3da7f934a1844288@mail.gmail.com> <1244476305.3661.167.camel@hermans.wildebeest.org> <4A2D6E47.6080907@sun.com> <17c6771e0906081442h970278fs33ddfb3715a9827d@mail.gmail.com> Message-ID: <1244499628.3661.181.camel@hermans.wildebeest.org> On Mon, 2009-06-08 at 22:42 +0100, Andrew John Hughes wrote: > 2009/6/8 Joseph D. Darcy : > > Mark Wielaard wrote: > >> On Sat, 2009-01-17 at 04:03 +0000, Andrew John Hughes wrote: > >>> 2009/1/17 Joseph D. Darcy : > >>>> > >>>> I'm happy to announce that within the next few months as part of > >>>> OpenJDK, we > >>>> are Sun are committed to open sourcing our Java Web Start implementation > >>>> and > >>>> the new plug-in implementation for NPAPI capable browsers; those > >>>> browsers > >>>> including Firefox 3, amongst others. > >>> > >>> Woo! Great news! > >> > >> This is indeed really great! > >> > >> It has been a few months now. Is there already a roadmap for how and > >> when the code will enter the repositories? Will it go into jdk6 first, > >> or will it go through jdk7. Will it be part of the M4 milestone that has > >> all the other 6u10 backported features? > > > > Since that posting, circumstances have changed and unfortunately there is no > > specific time line to share for the webstart and new plug-in code being > > available under open source. > > We'd better keep hacking on that replacement then... Yes indeed. I am happy people did keep hacking on the free replacements so that we have something for our user now that need an applet plugin or webstart functionality. But I am somewhat confused about what this really means. Isn't there any commitment anymore with Sun to release the implementation of the webstart and new plug-in code? What are the circumstances that changed? Is there anything the community can do to help? Thanks, Mark From Kelly.Ohair at Sun.COM Mon Jun 8 15:44:07 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 08 Jun 2009 15:44:07 -0700 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <17c6771e0906081440k72a2cdb6tad75653d1e7cbcce@mail.gmail.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> <4A2D6B4D.4020104@sun.com> <17c6771e0906081440k72a2cdb6tad75653d1e7cbcce@mail.gmail.com> Message-ID: <4A2D9437.7080901@sun.com> Andrew John Hughes wrote: > 2009/6/8 Kelly O'Hair : >> Someone from the hotspot team really needs to review this > > > Errr.... 4 of them already did: > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/2328d1d3f8cf Humm... ok, ... ... sorry... if this is in jdk7 already, then so be it. > > I'm not the author of this patch, I just backported it from OpenJDK7 > where it's been applied for over six months. I don't remember this > patch being reviewed openly and I disliked having all the fixes rolled > into one megafix like this. Yeah, I probably would have separated them, oh well. > But given this had been reviewed and was in 7, it seemed better to > backport this (just a matter of hg export/import) rather than trying > to get each individual IcedTea patch through, especially as one of > ours just turns off -Werror... (to some degree anyway) > Agreed. Matching jdk7 is the best route to take. > The relevant IcedTea patches are icedtea-fortify-source.patch (author: > Matthias Klose), hotspot/default/icedtea-format.patch (author: me), > icedtea-no-bcopy.patch (author: Matthias Klose), > hotspot/default/icedtea-gcc-4.3.patch (originally part of a patch by > Bernhard Rosenkraenzer according to the ChangeLog). > > , but my >> observations on these changes: >> >> * Changing the typedef for jlong seemed really risky to me, but I >> investigated it more and I'm pretty sure this is the right change, >> and forces it to match the public definition from jni.h/jni_md.h. >> So it looks right. >> > > It's kind of annoying it has to be defined repeatedly for each arch. Yeah... I think the idea of the xxx_md.h files was to avoid ifdef's, then we turn around and fill them with ifdef's :^{ Note that there has been a long standing issue that the jni*.h files in hotspot may not match the jni*.h files in the resulting jdk install image, they come from the copies checked into the jdk repository (see the directories jdk/src/{share,solaris,windows}/javavm/export). So one of these days, the public jni interface will be defined by hotspot 'and' it will deliver the jni include files too. ;^) > We also had to add this to Zero in IcedTea. > >> * The realpath() changes in src/os/linux/vm/os_linux.cpp seem to change >> the definition of this method when an error occurs, the control >> flow has changed, and I'm not exactly sure what the return value is >> when realpath() fails. I doubt realpath() fails very often here, >> but won't the buf[] array get some arbitrary directory when realpath() >> fails? Is that ok? That jvm_path() is a bizarre little method. :^{ >> > > In IcedTea, an unused variable is used which isn't ideal either, but > at least doesn't change the semantics. If the hotspot guys made this change in jdk7, I guess that's what they want. The 'gamma' and '_g' stuff isn't executed in most cases anyway. > >> * Changing the _lineno field in src/share/vm/utilities/vmError.hpp >> from an int to a size_t might seem right type wise, but sure seems >> like a waste of space. Does a lineno really need to use up 64bits of >> space? > > This doesn't seem to be patched in IcedTea, so I don't know the > reasoning for the change. Increasing the size to 64 bits on x86_64 > does seem wrong though. Yeah, seemed like it to me. Oh well. > >> * The *PTR* changes look right. >> > > Yeah, our patches are virtually identical on this :) > >> * The addition of an unused local variable like in >> src/share/vm/utilities/ostream.cpp >> to avoid a warning message just seems wrong to me, and will likely >> create a new warning message about an unused local variable. >> Seems like I've had this discussion before. >> I prefer an explicit (void) cast on a function call whose return >> value is not needed and I am frustrated with GCC's inability to >> understand what that (void) cast means. >> I really like the idea of using -Werror and not allowing warnings, >> but at times like this I have to wonder if we should just remove >> the -Werror unless we know that specific version of GCC is < 4.3. >> > > IcedTea does the same for this and the one above, but uses > __attribute__(unused) to avoid the warning. ok. I'm just never a fan of planting compiler implementation specifics into the source. -kto > >> But like I said, a 'real' hotspot developer should probably review this. ;^) >> >> -kto >> >> >> Andrew John Hughes wrote: >>> The following webrev: >>> >>> http://fuseyism.com/6781583/webrev.00/ >>> >>> is backported from OpenJDK7. It allows hs14 to be built using GCC 4.3 >>> and above. Otherwise, the build fails. IcedTea has been applying an >>> equivalent fix as three separately developed patches, two of which >>> have been there pretty much since its inception in the summer of 2007. >>> >>> Ok to commit? > > > From Paul.Hohensee at Sun.COM Mon Jun 8 16:06:19 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Mon, 08 Jun 2009 19:06:19 -0400 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <17c6771e0906081005w14655c3w58d6cecee6eed013@mail.gmail.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> <17c6771e0906081005w14655c3w58d6cecee6eed013@mail.gmail.com> Message-ID: <4A2D996B.6070206@sun.com> There seems to be some confusion here. hs14 is the version of hotspot that shipped with 6u14 and as such, is frozen. We do not intend to apply or allow any further bug fixes to it, including the one you propose here. It was never intended to be the basis for another openjdk version of hotspot. Ongoing hotspot development goes forward only in the openjdk hotspot repo, which is currently labeled hs16. Of course, anyone may feel free to clone hs14 if they like, and apply what fixes they will to said clone. One of those clones could easily be jdk6 open, but that's not our (the hotspot group's) decision to make. The next jdk6 update release will include a new version of hotspot, based either on hs14 (in which case it'll be an SSR, we'll likely call it hs14.1, and this fix will be off limits) or the current openjdk hotspot repo (in which case it will be a limited update, it'll likely be hs16, and the fix is already in it). The going-forward release is hs16. hs14 is a dead end. Paul Andrew John Hughes wrote: > 2009/6/8 Andrew John Hughes : > >> The following webrev: >> >> http://fuseyism.com/6781583/webrev.00/ >> >> is backported from OpenJDK7. It allows hs14 to be built using GCC 4.3 >> and above. Otherwise, the build fails. IcedTea has been applying an >> equivalent fix as three separately developed patches, two of which >> have been there pretty much since its inception in the summer of 2007. >> >> Ok to commit? >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >> >> > > It's in the webrev, but to be explicit: this is for the new hs14 tree. > From gnu_andrew at member.fsf.org Tue Jun 9 02:33:12 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 9 Jun 2009 10:33:12 +0100 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <4A2D996B.6070206@sun.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> <17c6771e0906081005w14655c3w58d6cecee6eed013@mail.gmail.com> <4A2D996B.6070206@sun.com> Message-ID: <17c6771e0906090233hd16cecah7dea33a817ff23cc@mail.gmail.com> 2009/6/9 Paul Hohensee : > There seems to be some confusion here. > Clearly, because what I believe we asked for was a stability branch and that was the point of going through this whole process for over three months. Why setup a forest unless it will be updated? > hs14 is the version of hotspot that shipped with 6u14 and as such, is > frozen. > We do not intend to apply or allow any further bug fixes to it, including > the > one you propose here. I'm not asking you to apply it. I'm suggesting that I do. It was never intended to be the basis for another > openjdk > version of hotspot. The entire __point__ of making hs14 available was to use it in OpenJDK6, at least from the point of view of IcedTea developers. ?Ongoing hotspot development goes forward only in the > openjdk hotspot repo, which is currently labeled hs16. ?Of course, anyone > may > feel free to clone hs14 if they like, and apply what fixes they will to said > clone. So you want us to create a fork? How does that help us all work together? > One of those clones could easily be jdk6 open, but that's not our (the > hotspot > group's) decision to make. > > The next jdk6 update release will include a new version of hotspot, based > either on hs14 (in which case it'll be an SSR, we'll likely call it hs14.1, > and this > fix will be off limits) Why? or the current openjdk hotspot repo (in which case > it > will be a limited update, it'll likely be hs16, and the fix is already in > it). ?The > going-forward release is hs16. ?hs14 is a dead end. > > Paul > > Andrew John Hughes wrote: >> >> 2009/6/8 Andrew John Hughes : >> >>> >>> The following webrev: >>> >>> http://fuseyism.com/6781583/webrev.00/ >>> >>> is backported from OpenJDK7. ?It allows hs14 to be built using GCC 4.3 >>> and above. ?Otherwise, the build fails. ?IcedTea has been applying an >>> equivalent fix as three separately developed patches, two of which >>> have been there pretty much since its inception in the summer of 2007. >>> >>> Ok to commit? >>> -- >>> Andrew :-) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> Support Free Java! >>> Contribute to GNU Classpath and the OpenJDK >>> http://www.gnu.org/software/classpath >>> http://openjdk.java.net >>> >>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>> >>> >> >> It's in the webrev, but to be explicit: this is for the new hs14 tree. >> > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Tue Jun 9 02:34:56 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 9 Jun 2009 10:34:56 +0100 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <4A2D9437.7080901@sun.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> <4A2D6B4D.4020104@sun.com> <17c6771e0906081440k72a2cdb6tad75653d1e7cbcce@mail.gmail.com> <4A2D9437.7080901@sun.com> Message-ID: <17c6771e0906090234u514372d5j86b8e5fb3dcb9094@mail.gmail.com> 2009/6/8 Kelly O'Hair : > > > Andrew John Hughes wrote: >> >> 2009/6/8 Kelly O'Hair : >>> >>> Someone from the hotspot team really needs to review this >> >> >> Errr.... 4 of them already did: >> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/2328d1d3f8cf > > Humm... ?ok, ... ... sorry... > if this is in jdk7 already, then so be it. > No apology required. It just shows this patch should have had an open review before being committed. >> >> I'm not the author of this patch, I just backported it from OpenJDK7 >> where it's been applied for over six months. ?I don't remember this >> patch being reviewed openly and I disliked having all the fixes rolled >> into one megafix like this. > > Yeah, I probably would have separated them, oh well. > >> But given this had been reviewed and was in 7, it seemed better to >> backport this (just a matter of hg export/import) rather than trying >> to get each individual IcedTea patch through, especially as one of >> ours just turns off -Werror... (to some degree anyway) >> > > Agreed. Matching jdk7 is the best route to take. > >> The relevant IcedTea patches are icedtea-fortify-source.patch (author: >> Matthias Klose), hotspot/default/icedtea-format.patch (author: me), >> icedtea-no-bcopy.patch (author: Matthias Klose), >> hotspot/default/icedtea-gcc-4.3.patch (originally part of a patch by >> Bernhard Rosenkraenzer according to the ChangeLog). >> >> , but my >>> >>> observations on these changes: >>> >>> ?* Changing the typedef for jlong seemed really risky to me, but I >>> ? investigated it more and I'm pretty sure this is the right change, >>> ? and forces it to match the public definition from jni.h/jni_md.h. >>> ? So it looks right. >>> >> >> It's kind of annoying it has to be defined repeatedly for each arch. > > Yeah... ?I think the idea of the xxx_md.h files was to avoid ifdef's, > then we turn around and fill them with ifdef's :^{ > > Note that there has been a long standing issue that the jni*.h files > in hotspot may not match the jni*.h files in the resulting jdk install > image, they come from the copies checked into the jdk repository > (see the directories jdk/src/{share,solaris,windows}/javavm/export). > So one of these days, the public jni interface will be defined by > hotspot 'and' it will deliver the jni include files too. ;^) > >> We also had to add this to Zero in IcedTea. >> >>> ?* The realpath() changes in src/os/linux/vm/os_linux.cpp seem to change >>> ? the definition of this method when an error occurs, the control >>> ? flow has changed, and I'm not exactly sure what the return value is >>> ? when realpath() fails. I doubt realpath() fails very often here, >>> ? but won't the buf[] array get some arbitrary directory when realpath() >>> ? fails? Is that ok? That jvm_path() is a bizarre little method. :^{ >>> >> >> In IcedTea, an unused variable is used which isn't ideal either, but >> at least doesn't change the semantics. > > If the hotspot guys made this change in jdk7, I guess that's what they > want. The 'gamma' and '_g' stuff isn't executed in most cases anyway. > >> >>> ?* Changing the _lineno field in src/share/vm/utilities/vmError.hpp >>> ? from an int to a size_t might seem right type wise, but sure seems >>> ? like a waste of space. Does a lineno really need to use up 64bits of >>> space? >> >> This doesn't seem to be patched in IcedTea, so I don't know the >> reasoning for the change. ?Increasing the size to 64 bits on x86_64 >> does seem wrong though. > > Yeah, seemed like it to me. Oh well. > >> >>> ?* The *PTR* changes look right. >>> >> >> Yeah, our patches are virtually identical on this :) >> >>> ?* The addition of an unused local variable like in >>> ? ? src/share/vm/utilities/ostream.cpp >>> ? to avoid a warning message just seems wrong to me, and will likely >>> ? create a new warning message about an unused local variable. >>> ? Seems like I've had this discussion before. >>> ? I prefer an explicit (void) cast on a function call whose return >>> ? value is not needed and I am frustrated with GCC's inability to >>> ? understand what that (void) cast means. >>> ? I really like the idea of using -Werror and not allowing warnings, >>> ? but at times like this I have to wonder if we should just remove >>> ? the -Werror unless we know that specific version of GCC is < 4.3. >>> >> >> IcedTea does the same for this and the one above, but uses >> __attribute__(unused) to avoid the warning. > > ok. > > I'm just never a fan of planting compiler implementation specifics into the > source. > Yeah, I'm not trying to defend it by any means :) > -kto > >> >>> But like I said, a 'real' hotspot developer should probably review this. >>> ;^) >>> >>> -kto >>> >>> >>> Andrew John Hughes wrote: >>>> >>>> The following webrev: >>>> >>>> http://fuseyism.com/6781583/webrev.00/ >>>> >>>> is backported from OpenJDK7. ?It allows hs14 to be built using GCC 4.3 >>>> and above. ?Otherwise, the build fails. ?IcedTea has been applying an >>>> equivalent fix as three separately developed patches, two of which >>>> have been there pretty much since its inception in the summer of 2007. >>>> >>>> Ok to commit? >> >> >> > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Paul.Hohensee at Sun.COM Tue Jun 9 04:00:56 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Tue, 09 Jun 2009 07:00:56 -0400 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <17c6771e0906090233hd16cecah7dea33a817ff23cc@mail.gmail.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> <17c6771e0906081005w14655c3w58d6cecee6eed013@mail.gmail.com> <4A2D996B.6070206@sun.com> <17c6771e0906090233hd16cecah7dea33a817ff23cc@mail.gmail.com> Message-ID: <4A2E40E8.3050606@sun.com> Yes, we want you to create a fork. We can work together on the fork. The hs14 repo isn't a clone of Sun's 6u14 hotspot repo, it _is_ our 6u14 hotspot repo. As such, we need it to stay as is so we can use it as the basis for customer one-offs containing single fixes, etc. Think of hs14 as a distro repo that happens to be public. Would it make sense for a company like Redhat to have allowed community changes to, say, it's ES 5.1 repo after it shipped? What we believed was asked for was a stable repo that could be used as the _basis_ for things like 6-open. As I said, feel free to clone hs14 for that purpose and then update the clone. Doing so seems to us to fulfill IcedTea developer requirements. SSRs are Synchronized Security Releases put out by Sun to fix particular security holes across all Sun-supported jdk releases at the same time. They contain only security fixes, so non-security fixes like this one are off-limits. What we call Limited Update Releases can contain other-than-security fixes. We alternate jdk6 update releases between SSRs and LURs. Paul Andrew John Hughes wrote: > 2009/6/9 Paul Hohensee : > >> There seems to be some confusion here. >> >> > > Clearly, because what I believe we asked for was a stability branch > and that was the point of going through this whole process for over > three months. Why setup a forest unless it will be updated? > > >> hs14 is the version of hotspot that shipped with 6u14 and as such, is >> frozen. >> We do not intend to apply or allow any further bug fixes to it, including >> the >> one you propose here. >> > > I'm not asking you to apply it. I'm suggesting that I do. > > It was never intended to be the basis for another > >> openjdk >> version of hotspot. >> > > The entire __point__ of making hs14 available was to use it in > OpenJDK6, at least from the point of view of IcedTea developers. > > Ongoing hotspot development goes forward only in the > >> openjdk hotspot repo, which is currently labeled hs16. Of course, anyone >> may >> feel free to clone hs14 if they like, and apply what fixes they will to said >> clone. >> > > So you want us to create a fork? How does that help us all work together? > > >> One of those clones could easily be jdk6 open, but that's not our (the >> hotspot >> group's) decision to make. >> >> The next jdk6 update release will include a new version of hotspot, based >> either on hs14 (in which case it'll be an SSR, we'll likely call it hs14.1, >> and this >> fix will be off limits) >> > > Why? > > or the current openjdk hotspot repo (in which case > >> it >> will be a limited update, it'll likely be hs16, and the fix is already in >> it). The >> going-forward release is hs16. hs14 is a dead end. >> >> Paul >> >> Andrew John Hughes wrote: >> >>> 2009/6/8 Andrew John Hughes : >>> >>> >>>> The following webrev: >>>> >>>> http://fuseyism.com/6781583/webrev.00/ >>>> >>>> is backported from OpenJDK7. It allows hs14 to be built using GCC 4.3 >>>> and above. Otherwise, the build fails. IcedTea has been applying an >>>> equivalent fix as three separately developed patches, two of which >>>> have been there pretty much since its inception in the summer of 2007. >>>> >>>> Ok to commit? >>>> -- >>>> Andrew :-) >>>> >>>> Free Java Software Engineer >>>> Red Hat, Inc. (http://www.redhat.com) >>>> >>>> Support Free Java! >>>> Contribute to GNU Classpath and the OpenJDK >>>> http://www.gnu.org/software/classpath >>>> http://openjdk.java.net >>>> >>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>> >>>> >>>> >>> It's in the webrev, but to be explicit: this is for the new hs14 tree. >>> >>> > > > > From martinrb at google.com Tue Jun 9 18:04:13 2009 From: martinrb at google.com (Martin Buchholz) Date: Tue, 9 Jun 2009 18:04:13 -0700 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <4A2E40E8.3050606@sun.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> <17c6771e0906081005w14655c3w58d6cecee6eed013@mail.gmail.com> <4A2D996B.6070206@sun.com> <17c6771e0906090233hd16cecah7dea33a817ff23cc@mail.gmail.com> <4A2E40E8.3050606@sun.com> Message-ID: <1ccfd1c10906091804j7c379f0by937829a70c60c714@mail.gmail.com> Paul, Thanks for the clear explanation. Given this, I'm thinking we lobby Joe Darcy to use a *copy* of hotspot 14 stable as the hotspot to use with OpenJDK6. Which can then evolve with community input. Andrew can do the first commit. Martin On Tue, Jun 9, 2009 at 04:00, Paul Hohensee wrote: > Yes, we want you to create a fork. We can work together on the fork. > > The hs14 repo isn't a clone of Sun's 6u14 hotspot repo, it _is_ our 6u14 > hotspot repo. As such, we need it to stay as is so we can use it as the > basis for customer one-offs containing single fixes, etc. Think of hs14 > as a distro repo that happens to be public. Would it make sense for > a company like Redhat to have allowed community changes to, say, it's > ES 5.1 repo after it shipped? > > What we believed was asked for was a stable repo that could be used > as the _basis_ for things like 6-open. As I said, feel free to clone hs14 > for > that purpose and then update the clone. Doing so seems to us to fulfill > IcedTea developer requirements. > > SSRs are Synchronized Security Releases put out by Sun to fix particular > security holes across all Sun-supported jdk releases at the same time. > They > contain only security fixes, so non-security fixes like this one are > off-limits. > What we call Limited Update Releases can contain other-than-security fixes. > We alternate jdk6 update releases between SSRs and LURs. > > > Paul > > Andrew John Hughes wrote: > >> 2009/6/9 Paul Hohensee : >> >> >>> There seems to be some confusion here. >>> >>> >>> >> >> Clearly, because what I believe we asked for was a stability branch >> and that was the point of going through this whole process for over >> three months. Why setup a forest unless it will be updated? >> >> >> >>> hs14 is the version of hotspot that shipped with 6u14 and as such, is >>> frozen. >>> We do not intend to apply or allow any further bug fixes to it, including >>> the >>> one you propose here. >>> >>> >> >> I'm not asking you to apply it. I'm suggesting that I do. >> >> It was never intended to be the basis for another >> >> >>> openjdk >>> version of hotspot. >>> >>> >> >> The entire __point__ of making hs14 available was to use it in >> OpenJDK6, at least from the point of view of IcedTea developers. >> >> Ongoing hotspot development goes forward only in the >> >> >>> openjdk hotspot repo, which is currently labeled hs16. Of course, anyone >>> may >>> feel free to clone hs14 if they like, and apply what fixes they will to >>> said >>> clone. >>> >>> >> >> So you want us to create a fork? How does that help us all work together? >> >> >> >>> One of those clones could easily be jdk6 open, but that's not our (the >>> hotspot >>> group's) decision to make. >>> >>> The next jdk6 update release will include a new version of hotspot, based >>> either on hs14 (in which case it'll be an SSR, we'll likely call it >>> hs14.1, >>> and this >>> fix will be off limits) >>> >>> >> >> Why? >> >> or the current openjdk hotspot repo (in which case >> >> >>> it >>> will be a limited update, it'll likely be hs16, and the fix is already in >>> it). The >>> going-forward release is hs16. hs14 is a dead end. >>> >>> Paul >>> >>> Andrew John Hughes wrote: >>> >>> >>>> 2009/6/8 Andrew John Hughes : >>>> >>>> >>>> >>>>> The following webrev: >>>>> >>>>> http://fuseyism.com/6781583/webrev.00/ >>>>> >>>>> is backported from OpenJDK7. It allows hs14 to be built using GCC 4.3 >>>>> and above. Otherwise, the build fails. IcedTea has been applying an >>>>> equivalent fix as three separately developed patches, two of which >>>>> have been there pretty much since its inception in the summer of 2007. >>>>> >>>>> Ok to commit? >>>>> -- >>>>> Andrew :-) >>>>> >>>>> Free Java Software Engineer >>>>> Red Hat, Inc. (http://www.redhat.com) >>>>> >>>>> Support Free Java! >>>>> Contribute to GNU Classpath and the OpenJDK >>>>> http://www.gnu.org/software/classpath >>>>> http://openjdk.java.net >>>>> >>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>> >>>>> >>>>> >>>>> >>>> It's in the webrev, but to be explicit: this is for the new hs14 tree. >>>> >>>> >>>> >>> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20090609/91da31b4/attachment.html From Paul.Hohensee at Sun.COM Tue Jun 9 19:44:35 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Tue, 09 Jun 2009 22:44:35 -0400 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <1ccfd1c10906091804j7c379f0by937829a70c60c714@mail.gmail.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> <17c6771e0906081005w14655c3w58d6cecee6eed013@mail.gmail.com> <4A2D996B.6070206@sun.com> <17c6771e0906090233hd16cecah7dea33a817ff23cc@mail.gmail.com> <4A2E40E8.3050606@sun.com> <1ccfd1c10906091804j7c379f0by937829a70c60c714@mail.gmail.com> Message-ID: <4A2F1E13.707@sun.com> Excellent idea. :) Paul Martin Buchholz wrote: > Paul, > Thanks for the clear explanation. > > Given this, I'm thinking we lobby Joe Darcy > to use a *copy* of hotspot 14 stable > as the hotspot to use with OpenJDK6. > Which can then evolve with community input. > Andrew can do the first commit. > > Martin > > On Tue, Jun 9, 2009 at 04:00, Paul Hohensee > wrote: > > Yes, we want you to create a fork. We can work together on the fork. > > The hs14 repo isn't a clone of Sun's 6u14 hotspot repo, it _is_ > our 6u14 > hotspot repo. As such, we need it to stay as is so we can use it > as the > basis for customer one-offs containing single fixes, etc. Think > of hs14 > as a distro repo that happens to be public. Would it make sense for > a company like Redhat to have allowed community changes to, say, it's > ES 5.1 repo after it shipped? > > What we believed was asked for was a stable repo that could be used > as the _basis_ for things like 6-open. As I said, feel free to > clone hs14 for > that purpose and then update the clone. Doing so seems to us to > fulfill > IcedTea developer requirements. > > SSRs are Synchronized Security Releases put out by Sun to fix > particular > security holes across all Sun-supported jdk releases at the same > time. They > contain only security fixes, so non-security fixes like this one > are off-limits. > What we call Limited Update Releases can contain > other-than-security fixes. > We alternate jdk6 update releases between SSRs and LURs. > > > Paul > > Andrew John Hughes wrote: > > 2009/6/9 Paul Hohensee >: > > > There seems to be some confusion here. > > > > > Clearly, because what I believe we asked for was a stability > branch > and that was the point of going through this whole process for > over > three months. Why setup a forest unless it will be updated? > > > > hs14 is the version of hotspot that shipped with 6u14 and > as such, is > frozen. > We do not intend to apply or allow any further bug fixes > to it, including > the > one you propose here. > > > > I'm not asking you to apply it. I'm suggesting that I do. > > It was never intended to be the basis for another > > > openjdk > version of hotspot. > > > > The entire __point__ of making hs14 available was to use it in > OpenJDK6, at least from the point of view of IcedTea developers. > > Ongoing hotspot development goes forward only in the > > > openjdk hotspot repo, which is currently labeled hs16. Of > course, anyone > may > feel free to clone hs14 if they like, and apply what fixes > they will to said > clone. > > > > So you want us to create a fork? How does that help us all > work together? > > > > One of those clones could easily be jdk6 open, but that's > not our (the > hotspot > group's) decision to make. > > The next jdk6 update release will include a new version of > hotspot, based > either on hs14 (in which case it'll be an SSR, we'll > likely call it hs14.1, > and this > fix will be off limits) > > > > Why? > > or the current openjdk hotspot repo (in which case > > > it > will be a limited update, it'll likely be hs16, and the > fix is already in > it). The > going-forward release is hs16. hs14 is a dead end. > > Paul > > Andrew John Hughes wrote: > > > 2009/6/8 Andrew John Hughes >: > > > > The following webrev: > > http://fuseyism.com/6781583/webrev.00/ > > is backported from OpenJDK7. It allows hs14 to be > built using GCC 4.3 > and above. Otherwise, the build fails. IcedTea > has been applying an > equivalent fix as three separately developed > patches, two of which > have been there pretty much since its inception in > the summer of 2007. > > Ok to commit? > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C > 2591 94EF D9D8 > > > > > It's in the webrev, but to be explicit: this is for > the new hs14 tree. > > > > > > > > > From Joe.Darcy at Sun.COM Wed Jun 10 00:02:47 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Wed, 10 Jun 2009 00:02:47 -0700 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <4A2F1E13.707@sun.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> <17c6771e0906081005w14655c3w58d6cecee6eed013@mail.gmail.com> <4A2D996B.6070206@sun.com> <17c6771e0906090233hd16cecah7dea33a817ff23cc@mail.gmail.com> <4A2E40E8.3050606@sun.com> <1ccfd1c10906091804j7c379f0by937829a70c60c714@mail.gmail.com> <4A2F1E13.707@sun.com> Message-ID: <4A2F5A97.9080805@sun.com> Myself and much of the Sun JDK team is out of the office this week. I'll consider Martin's suggestion and other approaches to this issue when I get back into the office next week. -Joe Paul Hohensee wrote: > Excellent idea. :) > > Paul > > Martin Buchholz wrote: >> Paul, >> Thanks for the clear explanation. >> >> Given this, I'm thinking we lobby Joe Darcy >> to use a *copy* of hotspot 14 stable >> as the hotspot to use with OpenJDK6. >> Which can then evolve with community input. >> Andrew can do the first commit. >> >> Martin >> >> On Tue, Jun 9, 2009 at 04:00, Paul Hohensee > > wrote: >> >> Yes, we want you to create a fork. We can work together on the >> fork. >> >> The hs14 repo isn't a clone of Sun's 6u14 hotspot repo, it _is_ >> our 6u14 >> hotspot repo. As such, we need it to stay as is so we can use it >> as the >> basis for customer one-offs containing single fixes, etc. Think >> of hs14 >> as a distro repo that happens to be public. Would it make sense for >> a company like Redhat to have allowed community changes to, say, >> it's >> ES 5.1 repo after it shipped? >> >> What we believed was asked for was a stable repo that could be used >> as the _basis_ for things like 6-open. As I said, feel free to >> clone hs14 for >> that purpose and then update the clone. Doing so seems to us to >> fulfill >> IcedTea developer requirements. >> >> SSRs are Synchronized Security Releases put out by Sun to fix >> particular >> security holes across all Sun-supported jdk releases at the same >> time. They >> contain only security fixes, so non-security fixes like this one >> are off-limits. >> What we call Limited Update Releases can contain >> other-than-security fixes. >> We alternate jdk6 update releases between SSRs and LURs. >> >> >> Paul >> >> Andrew John Hughes wrote: >> >> 2009/6/9 Paul Hohensee > >: >> >> There seems to be some confusion here. >> >> >> >> Clearly, because what I believe we asked for was a stability >> branch >> and that was the point of going through this whole process for >> over >> three months. Why setup a forest unless it will be updated? >> >> >> hs14 is the version of hotspot that shipped with 6u14 and >> as such, is >> frozen. >> We do not intend to apply or allow any further bug fixes >> to it, including >> the >> one you propose here. >> >> >> I'm not asking you to apply it. I'm suggesting that I do. >> >> It was never intended to be the basis for another >> >> openjdk >> version of hotspot. >> >> >> The entire __point__ of making hs14 available was to use it in >> OpenJDK6, at least from the point of view of IcedTea developers. >> >> Ongoing hotspot development goes forward only in the >> >> openjdk hotspot repo, which is currently labeled hs16. Of >> course, anyone >> may >> feel free to clone hs14 if they like, and apply what fixes >> they will to said >> clone. >> >> >> So you want us to create a fork? How does that help us all >> work together? >> >> >> One of those clones could easily be jdk6 open, but that's >> not our (the >> hotspot >> group's) decision to make. >> >> The next jdk6 update release will include a new version of >> hotspot, based >> either on hs14 (in which case it'll be an SSR, we'll >> likely call it hs14.1, >> and this >> fix will be off limits) >> >> >> Why? >> >> or the current openjdk hotspot repo (in which case >> >> it >> will be a limited update, it'll likely be hs16, and the >> fix is already in >> it). The >> going-forward release is hs16. hs14 is a dead end. >> >> Paul >> >> Andrew John Hughes wrote: >> >> 2009/6/8 Andrew John Hughes > >: >> >> >> The following webrev: >> >> http://fuseyism.com/6781583/webrev.00/ >> >> is backported from OpenJDK7. It allows hs14 to be >> built using GCC 4.3 >> and above. Otherwise, the build fails. IcedTea >> has been applying an >> equivalent fix as three separately developed >> patches, two of which >> have been there pretty much since its inception in >> the summer of 2007. >> >> Ok to commit? >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C >> 2591 94EF D9D8 >> >> >> >> It's in the webrev, but to be explicit: this is for >> the new hs14 tree. >> >> >> >> >> >> >> From gnu_andrew at member.fsf.org Wed Jun 10 08:37:25 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 10 Jun 2009 16:37:25 +0100 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <4A2E40E8.3050606@sun.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> <17c6771e0906081005w14655c3w58d6cecee6eed013@mail.gmail.com> <4A2D996B.6070206@sun.com> <17c6771e0906090233hd16cecah7dea33a817ff23cc@mail.gmail.com> <4A2E40E8.3050606@sun.com> Message-ID: <17c6771e0906100837i2e5176bbvcbed36a8f0216511@mail.gmail.com> 2009/6/9 Paul Hohensee : > Yes, we want you to create a fork. ?We can work together on the fork. > > The hs14 repo isn't a clone of Sun's 6u14 hotspot repo, it _is_ our 6u14 > hotspot repo. ?As such, we need it to stay as is so we can use it as the > basis for customer one-offs containing single fixes, etc. ?Think of hs14 > as a distro repo that happens to be public. ?Would it make sense for > a company like Redhat to have allowed community changes to, say, it's > ES 5.1 repo after it shipped? > I'm sorry, but I can't follow your logic here. From what you've said in previous emails and simple common sense, I can't see these customer one-offs being created one on top of each other in the public repository. So what you seem to be saying is you need to keep the tip of the repository the same as it is now for these private forks - why not just tag the tree at this point and use that tag for future private forks for customer one-offs? Things would be much easier generally if the HotSpot 'releases' (hs16b03, etc.) were tagged, as I believe has been mentioned before. > What we believed was asked for was a stable repo that could be used > as the _basis_ for things like 6-open. ?As I said, feel free to clone hs14 > for > that purpose and then update the clone. ?Doing so seems to us to fulfill > IcedTea developer requirements. > To be honest, it doesn't really matter that much whether we use hsx or a clone to me; I'm just trying to understand why effort was put into creating a forest which is essentially frozen in time. What worries me is that this discussion keeps throwing up 'us' and 'them' scenarios, as you refer to here with 'IcedTea developer requirements'. I thought we were trying to work together as an OpenJDK community which includes those inside Sun and those outside it (which is represented by our newly expanded IGB). As far as IcedTea requirements are concerned, the mere availability of an updated hs14 has allowed us to ship IcedTea6 1.5 with this included. The push for updating OpenJDK6 and making it actually buildable on a modern system is because we want OpenJDK itself to succeed for the benefit of everyone. That's the last thing I'm going to add with regard to this, as the whole conversation seems to have gone on too long and doesn't appear to be getting us anywhere. Please just let us know when there is a hs14 available somewhere to which we can contribute our patches. > SSRs are Synchronized Security Releases put out by Sun to fix particular > security holes across all Sun-supported jdk releases at the same time. ?They > contain only security fixes, so non-security fixes like this one are > off-limits. > What we call Limited Update Releases can contain other-than-security fixes. > We alternate jdk6 update releases between SSRs and LURs. > > Paul > > Andrew John Hughes wrote: >> >> 2009/6/9 Paul Hohensee : >> >>> >>> There seems to be some confusion here. >>> >>> >> >> Clearly, because what I believe we asked for was a stability branch >> and that was the point of going through this whole process for over >> three months. ?Why setup a forest unless it will be updated? >> >> >>> >>> hs14 is the version of hotspot that shipped with 6u14 and as such, is >>> frozen. >>> We do not intend to apply or allow any further bug fixes to it, including >>> the >>> one you propose here. >>> >> >> I'm not asking you to apply it. ?I'm suggesting that I do. >> >> It was never intended to be the basis for another >> >>> >>> openjdk >>> version of hotspot. >>> >> >> The entire __point__ of making hs14 available was to use it in >> OpenJDK6, at least from the point of view of IcedTea developers. >> >> ?Ongoing hotspot development goes forward only in the >> >>> >>> openjdk hotspot repo, which is currently labeled hs16. ?Of course, anyone >>> may >>> feel free to clone hs14 if they like, and apply what fixes they will to >>> said >>> clone. >>> >> >> So you want us to create a fork? ?How does that help us all work together? >> >> >>> >>> One of those clones could easily be jdk6 open, but that's not our (the >>> hotspot >>> group's) decision to make. >>> >>> The next jdk6 update release will include a new version of hotspot, based >>> either on hs14 (in which case it'll be an SSR, we'll likely call it >>> hs14.1, >>> and this >>> fix will be off limits) >>> >> >> Why? >> >> or the current openjdk hotspot repo (in which case >> >>> >>> it >>> will be a limited update, it'll likely be hs16, and the fix is already in >>> it). ?The >>> going-forward release is hs16. ?hs14 is a dead end. >>> >>> Paul >>> >>> Andrew John Hughes wrote: >>> >>>> >>>> 2009/6/8 Andrew John Hughes : >>>> >>>> >>>>> >>>>> The following webrev: >>>>> >>>>> http://fuseyism.com/6781583/webrev.00/ >>>>> >>>>> is backported from OpenJDK7. ?It allows hs14 to be built using GCC 4.3 >>>>> and above. ?Otherwise, the build fails. ?IcedTea has been applying an >>>>> equivalent fix as three separately developed patches, two of which >>>>> have been there pretty much since its inception in the summer of 2007. >>>>> >>>>> Ok to commit? >>>>> -- >>>>> Andrew :-) >>>>> >>>>> Free Java Software Engineer >>>>> Red Hat, Inc. (http://www.redhat.com) >>>>> >>>>> Support Free Java! >>>>> Contribute to GNU Classpath and the OpenJDK >>>>> http://www.gnu.org/software/classpath >>>>> http://openjdk.java.net >>>>> >>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>>>> >>>>> >>>>> >>>> >>>> It's in the webrev, but to be explicit: this is for the new hs14 tree. >>>> >>>> >> >> >> >> > Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From sean.mullan at sun.com Wed Jun 10 13:49:16 2009 From: sean.mullan at sun.com (sean.mullan at sun.com) Date: Wed, 10 Jun 2009 20:49:16 +0000 Subject: hg: jdk6/jdk6/jdk: 6845161: Bottleneck in Configuration.getConfiguration synchronized call Message-ID: <20090610204935.C7FDCE30D@hg.openjdk.java.net> Changeset: 93de0eebebd6 Author: mullan Date: 2009-06-10 13:37 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/93de0eebebd6 6845161: Bottleneck in Configuration.getConfiguration synchronized call Summary: Reduce scope of synchronized block Reviewed-by: weijun ! src/share/classes/javax/security/auth/login/Configuration.java From Dalibor.Topic at Sun.COM Wed Jun 17 21:12:50 2009 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Thu, 18 Jun 2009 06:12:50 +0200 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <4A2F1E13.707@sun.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> <17c6771e0906081005w14655c3w58d6cecee6eed013@mail.gmail.com> <4A2D996B.6070206@sun.com> <17c6771e0906090233hd16cecah7dea33a817ff23cc@mail.gmail.com> <4A2E40E8.3050606@sun.com> <1ccfd1c10906091804j7c379f0by937829a70c60c714@mail.gmail.com> <4A2F1E13.707@sun.com> Message-ID: <4A39BEC2.4050706@sun.com> Paul Hohensee wrote: > Excellent idea. :) > > Paul > > Martin Buchholz wrote: >> Paul, >> Thanks for the clear explanation. >> >> Given this, I'm thinking we lobby Joe Darcy >> to use a *copy* of hotspot 14 stable >> as the hotspot to use with OpenJDK6. >> Which can then evolve with community input. >> Andrew can do the first commit. I agree. The hsx team can easily keep the gcc version they use stable, so they don't need to introduce changes to make hsx code work with latest gcc releases. OpenJDK 6, otoh, is used in distributions that ship bleeding edge gccs, so it needs to keep evolving along with gcc, which implies two different drivers, and that's a good reason to copy and go. In order to avoid accumulating gcc patchlets monotonously in OpenJDK 6 clone of hsx, such fixes should also be submitted to the hotspot team, where they apply to the in development version of hotspot. cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin H?ring From gnu_andrew at member.fsf.org Thu Jun 18 07:10:25 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 18 Jun 2009 15:10:25 +0100 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <4A39BEC2.4050706@sun.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> <17c6771e0906081005w14655c3w58d6cecee6eed013@mail.gmail.com> <4A2D996B.6070206@sun.com> <17c6771e0906090233hd16cecah7dea33a817ff23cc@mail.gmail.com> <4A2E40E8.3050606@sun.com> <1ccfd1c10906091804j7c379f0by937829a70c60c714@mail.gmail.com> <4A2F1E13.707@sun.com> <4A39BEC2.4050706@sun.com> Message-ID: <17c6771e0906180710v5ea30dd8qe8b09f684cb78dc7@mail.gmail.com> 2009/6/18 Dalibor Topic : > Paul Hohensee wrote: >> Excellent idea. :) >> >> Paul >> >> Martin Buchholz wrote: >>> Paul, >>> Thanks for the clear explanation. >>> >>> Given this, I'm thinking we lobby Joe Darcy >>> to use a *copy* of hotspot 14 stable >>> as the hotspot to use with OpenJDK6. >>> Which can then evolve with community input. >>> Andrew can do the first commit. > > I agree. The hsx team can easily keep the gcc version they use > stable, so they don't need to introduce changes to make hsx code > work with latest gcc releases. OpenJDK 6, otoh, is used in > distributions that ship bleeding edge gccs, so it needs to keep > evolving along with gcc, which implies two different drivers, and > that's a good reason to copy and go. > I wouldn't call 4.3 'bleeding edge'. it's over a year since it was released. Heck, even Debian has it (though I guess it's not in RHEL). No one has yet adequately explained why we now have a 'read only' HotSpot repository. This isn't about the HotSpot team wanting to keep using an old version of gcc - this patch is a backported from the HotSpot tree. > In order to avoid accumulating gcc patchlets monotonously in > OpenJDK 6 clone of hsx, such fixes should also be submitted > to the hotspot team, where they apply to the in development > version of hotspot. > Well, yes. Indeed I'd expect them to be applied to the HotSpot tree *first* and then backported to the *stable* OpenJDK6 tree as appropriate. Speaking of which, can we have an HotSpot tree we can actually *commit to* sometime soon? > cheers, > dalibor topic > -- > ******************************************************************* > Dalibor Topic ? ? ? ? ? ? ? ? ? Tel: (+49 40) 23 646 738 > Java F/OSS Ambassador ? ? ? ? ? AIM: robiladonaim > Sun Microsystems GmbH ? ? ? ? ? Mobile: (+49 177) 2664 192 > Nagelsweg 55 ? ? ? ? ? ? ? ? ? ?http://openjdk.java.net > D-20097 Hamburg ? ? ? ? ? ? ? ? mailto:Dalibor.Topic at sun.com > Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten > Amtsgericht M?nchen: HRB 161028 > Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel > Vorsitzender des Aufsichtsrates: Martin H?ring > > > Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From langel at redhat.com Fri Jun 19 11:44:23 2009 From: langel at redhat.com (langel at redhat.com) Date: Fri, 19 Jun 2009 18:44:23 +0000 Subject: hg: jdk6/jdk6/jdk: 6721086: Toolkit beep does not work consistently Message-ID: <20090619184437.BFCE4ECF2@hg.openjdk.java.net> Changeset: 513c04078994 Author: langel Date: 2009-06-19 14:35 -0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/513c04078994 6721086: Toolkit beep does not work consistently Summary: Flush out after bell is sounded Reviewed-by: anthony ! src/solaris/classes/sun/awt/X11/XToolkit.java From kelly.ohair at sun.com Fri Jun 19 17:10:13 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Sat, 20 Jun 2009 00:10:13 +0000 Subject: hg: jdk6/jdk6/jdk: 6853243: JPRT build problem, not bundling LICENSE file needed for image creation Message-ID: <20090620001023.67F79EDD4@hg.openjdk.java.net> Changeset: fe1df6f56a29 Author: ohair Date: 2009-06-19 17:03 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/fe1df6f56a29 6853243: JPRT build problem, not bundling LICENSE file needed for image creation Reviewed-by: tbell ! make/jprt.properties From kelly.ohair at sun.com Fri Jun 19 17:26:46 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Sat, 20 Jun 2009 00:26:46 +0000 Subject: hg: jdk6/jdk6: 6853243: JPRT build problem, not bundling LICENSE file needed for image creation Message-ID: <20090620002646.82537EDDA@hg.openjdk.java.net> Changeset: a37eb5283992 Author: ohair Date: 2009-06-19 17:20 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/rev/a37eb5283992 6853243: JPRT build problem, not bundling LICENSE file needed for image creation Reviewed-by: tbell ! make/jprt.properties