HotSpot 14

[Joseph D. Darcy]

Jonathan Gibbons wrote:
> 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.

For HotSpot, another way to implement this approach is to sync HS 14 
into OpenJDK 6 and then do whatever would have been done in the new HSX 
repo in the existing OpenJDK 6 repo.

For corba, jaxp, and jaxws which are effectively maintained elsewhere, 
later this year I want to explore going to a model where those files are 
*not* tracked under version control in the JDK, rather the teams in 
question would periodically sent us known-good source tar-balls, or some 
equivalent bundle of code.  Any JDK-specific changes could be tracked 
under version control and applied locally as patches until the changes 
go upstream.

Given how well this model works for IcedTea working with OpenJDK, I'm 
confident it can also work for the JDK's incorporation of corba, jaxp, 
and jaxws :-)

-Joe