HotSpot 14

[Jonathan Gibbons]

On May 15, 2009, at 9:58 PM, Joseph D. Darcy wrote:

> Hello.
>
> Erik Trimble wrote:
>> Andrew John Hughes wrote:
>>> 2009/5/15 Erik Trimble <Erik.Trimble at sun.com>:
>>>
>>>> Andrew John Hughes wrote:
>>>>
>>>>> Hi all (especially Joe),
>>>>>
>>>>> Now that the HotSpot Express repositories are available, what is  
>>>>> the
>>>>> plan for including hs14 in OpenJDK6?
>>>>>
>>>>> I did a pull of the base changeset from HS express (0) into  
>>>>> OpenJDK6's
>>>>> hotspot repo. yesterday as a test, and it seems to apply fairly  
>>>>> well.
>>>>> The conflicts all seem to be whitespace changes (though there's  
>>>>> a lot
>>>>> of them -- ~210 files are affected).
>>>>>
>>>>> Do we still plan to maintain a version of HotSpot in OpenJDK6 or  
>>>>> will
>>>>> HS Express just be used directly?
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>> Frankly, I think this is up to the Community.
>>>>
>>>> I'm still not 100% sure of the complete list of who has write  
>>>> access to the
>>>> OpenJDK6 stuff, but I /think/ the proper way to do this is not  
>>>> move any HSX
>>>> release into the main OpenJDK6 forest until there is  consensus  
>>>> that It's
>>>> Time.
>>>>
>>>>
>>>
>>> The list is here: http://db.openjdk.java.net/people for your
>>> delectation and delight.
>>>
>>>
>> Thanks!
>>
>>
>>>> Now, that said, maybe It's Time Right Now.
>>>>
>>>>
>>>
>>> IcedTea (i.e. the version of OpenJDK6 people are actually using on
>>> their distros today) has already been shipping HotSpot 14 for some
>>> time.  So I think not only is the time right for OpenJDK6 upstream  
>>> to
>>> also upgrade, but that it's perhaps long overdue.
>>>
>>>
>> I'll check with Joe, but I think it's on my to-do list to push  
>> HSX14 to OpenJDK sometime before JavaOne.
>
> That sounds good to me, modulo my preferences below...
>
>>>> Given that the HSX repos are going to be almost exclusively Sun- 
>>>> only
>>>> writable (in practice, not necessarily by design), I think that  
>>>> the VM in
>>>> OpenJDK6 should be pulled from an HSX repo, and then have various
>>>> community-desired patches applied there, rather than try to work  
>>>> directly on
>>>> an HSX repo.  That is, I expect the various HSX repos to be a  
>>>> reflection of
>>>> what Sun is doing, and the VM in OpenJDK6 should be a reflection  
>>>> of what the
>>>> Community chooses to do with the HSX work from Sun.
>>>>
>>>>
>>>
>>> My preference would be for patches to go into HotSpot Express and  
>>> then
>>> OpenJDK6 just pull a stable version regularly.  I've already had
>>> patches committed to HotSpot as have others working on IcedTea, so I
>>> don't see an issue there.
>>>
>>
>> Well, this needs further discussion.  There's still some conflict  
>> here as to whether or not we're going to ship the Sun JDK 6 Update  
>> release train as a superset of the OpenJDK6 + HSX repositories, or  
>> if there will be things in those open repos that we exclude from  
>> the Sun JDK6 Updates.
>>
>> If the first case is what is happening (i.e. Sun's JDK is a  
>> superset of OpenJDK6+HSX), then, yes, we (that is, the entire  
>> Community+Sun) should just patch the appropriate HSX repo, and  
>> periodically pull it over into the OpenJDK6 forest after  
>> stabilization.   If, on the other hand, the second case is what is  
>> To Be, then only certain community-submitted patches will be  
>> integrated into HSX, which means that the actual development of  
>> Hotspot for OpenJDK6 will have to happen in the OpenJDK6 forest  
>> directly.  In essence, if we chose the 2nd case, there will need to  
>> be 3 VM repositories:   HSX for the stuff that's going to be the  
>> Sun JDK6 release, IceTea for the patches to the HSX repository that  
>> aren't going into Sun's JDK, and OpenJDK6, which is HSX+IceTea  
>> (stabilized).
>>
>
> In my estimation, the fixes desirable in a HS repository being used  
> for Sun JDK stabilization and the fixes desirable for a HS  
> repository being used for OpenJDK 6 and for IcedTea 6 are  
> fundamentally the same in all cases: a stable HotSpot that runs fast  
> enough.  Around the margins, there may be some issues around if a  
> particular patch is appropriate for the upstream sources, but the  
> IcedTea HotSpot patches I've seen to fix things like build issues  
> seem innocuous and appropriate for upstream to me.
>
> My preference is essentially combining the HSX and OpenJDK 6 HS  
> repositories; i.e. the OpenJDK 6 HS repository is the HSX  
> stabilization repo.  The alternative of periodically syncing HSX  
> into OpenJDK 6 is possible too, but strikes me as a little extra  
> work when we could just as easily tag or otherwise publicize "we  
> think this version of the repo is good."  The IcedTea HS patches  
> could continue as needed, especially timing wise when release  
> deadlines don't line up, but I think we should be able to get much  
> less skew between the HotSpot in IcedTea and the stabilized HS in  
> OpenJDK 6/HSX, which should bring benefits all around by getting  
> more testing on (nearly) the same code base.
>
> -Joe


Joe,

Architecturally, this seems to bring up an interesting point.  
Currently we build a set of "co-located" repositories -- i.e. a  
Mercurial forest.  You are somewhat suggesting we break this paradigm,  
by using a tree (HotSpot) which is not directly within the forest.  If  
we can figure out how to do that, then maybe we would also be able to  
use the same mechanism to handle corba/jaxws, jaxp, etc, which do not  
naturally live within our forests.

Maybe the top level repo could have optional Makefile targets to get  
copies of the latest preferred copies of these "imported"  
repositories.  They would be "optional" in that they would be  
available for a user to invoke if they wanted to access and build  
using the imported repository, as compared to using the existing  
mechanism for importing built bits from an earlier build.

-- Jon