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.trim...@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
