[RFC] Enhanced Garbage Collection Probe Points
gnu.andrew at redhat.com
Fri Nov 2 07:53:47 PDT 2012
----- Original Message -----
> On Thu, 2012-11-01 at 14:32 -0400, Jon VanAlten wrote:
> > I would also prefer the 7 stuff to go to the forest, but...
> > > From: "Mark Wielaard" <mark at klomp.org>
> > <SNIP>
> > >
> > > Adding patches directly to the tree is fine with me.
> > > My only hesitation was my own confusion since the default
> > > configure/make setup doesn't pick up a patched forest.
> > > You don't have that issue with patches, which are directly
> > > applied. If we are going for a complete forest setup it
> > > might make sense to also add the tapsets and testsuite
> > > directly there.
> > >
> > > I'll try and figure it all out again and also port the existing
> > > patches to the forest. Hints and tips appreciated.
> > So about this patch and 7, I'm getting mixed messages here.
Mark, is this the whole of your patch or only part of it?
i.e. could that be added to forest and systemtap.patch removed from IcedTea7?
> What is the mixed message? I am fine with adding patches directly to
> forest and even adding the other stuff like the tapsets and the
> staptests there. I just don't know the workflow when I would work
> against the forest directly and not just have patches in the tree.
> And I
> just haven't found the time to create a new workflow. I am sure it is
> just a different ./configure flag, just haven't figured out which
> So, how do people work against the forest directly? What configure
> do they use? What does your edit/build/test/commit/pull cycle look
> Basically the only step I seem to miss is how to make sure the tree
> in sync with what I push to the forest. Somehow I am missing how when
> commit to the forest the icedtea tree is updated so people who update
> their tree get the new patch. Knowing how that works would also help
> with making sure the buildbot rebuilds the tree each time the forest
> changed and not only when a patch is added to the tree.
It's a two stage process:
1. Work against the forest, make sure it builds and then commit.
2. Sync IcedTea7 with the latest forest revisions.
For 1, the IcedTea forest (or any OpenJDK tree) can be built with something
(you don't need all that; it's designed for maximum flexibility).
For stage 2, you need to update the changeset and checksums in IcedTea7.
There's a script to do that for you using the latest tip of each repo.
See scripts/update_tarballs.sh. You then do a build and, if it's successful
with the new tarballs, it can be pushed with the usual ChangeLog.
There is no automation of updating IcedTea7 to match the forest as in many
cases it requires some manual work. For example, pushing SystemTap to the
forest also requires removing the patch in IcedTea7. Likewise, when there is
a big upstream merge, bootstrapping often breaks so the bootstrap patches may
need to be updated.
Also, as updating may also pull in other people's changesets, it's important
to announce your intentions on the mailing list before doing so. Pulling in
an upstream update that hasn't yet been synced with the forest is going to
give you a lot more work to do and possibly duplicate work being done by myself.
It may be appropriate to delegate 2 in this case, if you have a fairly minor
change but there is a mass of other larger changes coming through too.
A typical update for an upstream sync would be:
2012-09-25 Andrew John Hughes <gnu_andrew at member.fsf.org>
(OPENJDK_VERSION): Bump to b08.
(CORBA_CHANGESET): Update to IcedTea7 forest head.
* hotspot.map: Update default to head of IcedTea7
Regenerated. Added new cases in javax.crypto.CryptoPermissions,
javax.crypto.JceSecurityManager and java.beans.Introspector.
Added new case in sun.tools.jconsole.Resources.
which reminds me I should update the scripts to better handle the multiple HotSpots
we now have to support due to Zero...
If you want to have a builder building against the upstream forest rather than
the supported set of changesets & checksums, this can be done with 6, 7 & 8.
The option --with-openjdk-src-dir can be used to point to a forest checkout.
I use this to maintain icedtea6-hg which compiles against upstream OpenJDK6,
not a tarball. You may see failures being posted from this when OpenJDK6 is updated
and not yet in sync.
There's also --enable-hg which does the checkout for you, but this isn't heavily
maintained; I don't use it and I believe it still uses the obsolete forest extension.
It's also inefficient as it does a completely fresh checkout when it makes more sense
to do one manual checkout and reuse it.
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
More information about the distro-pkg-dev