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