On Dec 4, 2008, at 12:35 AM, Ben Evans wrote:
Apologies if this is not the right place to ask (or if there are
basic docs somewhere which I have failed to find on my own).
I've been following the build instructions at:
http://wikis.sun.com/display/mlvm/Building
and trying to build with b33 of OpenJDK7, from the bsd port, to
then build via:
http://landonf.bikemonkey.org/code/java/SoyLatte_Meets_OpenJDK.
20080819.html
(I have successfully built a vanilla OpenJDK7 and aside from some
known problems with the test suite, seem to have it self-hosting).
I currently develop mlvm on Solaris over VMWare on my MacBook (OSX
10.4 though). I'm excited to see you working on OSX builds. The bad
news is, you are the pioneer.
I've given you full write permissions on the mlvm wiki, in case you
want to share your experiences more fully.
Unfortunately, the patches for invokedynamic do not seem to apply
against my bsd src tree.
The patches in the mlvm repositories are based against whatever
recent JDK version somebody (me, in practice) has refreshed them
against.
The .hg/patches/series file advertises (by convention) which build
each patch applies to.
In the mlvm/hotspot repo, the patches are refreshed to b38 but in
practice they should work against neighboring builds, including b40.
The patches in mlvm/jdk are refreshed to b34, which is close enough
to b38. See:
http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/series
http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/series
Your $guards variable probably says b40 (based on the reading
of .hgtags by make/current-release.sh). Change it to mention all the
builds the patches expect, both b34 and b38. This amounts to a
manual override that says "yes, I know this base is not exactly what
the patches want, and I'll take responsibility for the
consequences". You might have patch mismatches to fix and/or build
problems.
One big change: You'll have to manually delete anonk.patch from the
patches/hotspot/series if you are building against a JDK that has
anonk in it. (I pushed that recently out of the patch repo.)
If you want more direct access to the guard state, just do this:
head patches/*/guards
Patches are controlled by a flat text file you can vi or emacs.
If you would like to refresh the patches to b40, please send me meta-
patchs (hg diff -R patches/{hotspot,jdk}). There's a little bit of
paperwork: You'll need to sign the SCA (https://sca.dev.java.net/)
and it would help to have your java.net handle (evansben?).
I'll probably do the next mlvm push in a week or two. (I'm doing a
round of spec work which will sooner or later show up in the RI.)
Eg, after applying the patches via:
CatBasket:sources boxcat$ sh patches/make/each-patch-repo.sh hg
qselect --reapply $guards
the only matches I have are:
CatBasket:jdk boxcat$ grep -rin methodhandle . | grep -v patches
./src/share/classes/com/sun/jndi/toolkit/corba/CorbaUtils.java:
87: initMethodHandles();
./src/share/classes/com/sun/jndi/toolkit/corba/CorbaUtils.java:
215: private static void initMethodHandles() throws
ClassNotFoundException {
CatBasket:jdk boxcat$ pwd
/Users/boxcat/projects/jdk7-b33/sources/jdk
CatBasket:jdk boxcat$
Try this command to see which guards are enabled:
sh patches/make/each-patch-repo.sh hg qguard
head patches/*/guards # quick & dirty form
Try this command to see which patches are (therefore) enabled:
sh patches/make/each-patch-repo.sh hg qseries
Let me know which of these comments helps, if any do.
Best wishes,
-- John
_______________________________________________
mlvm-dev mailing list
[email protected]
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
