You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2006/06/23 20:01:32 UTC
Re: [drlvm] Doing the minimum to support Java 5 classfiles
On 23 June 2006 at 17:10, Tim Ellison <t....@gmail.com> wrote:
> Rana Dasgupta wrote:
> > On 6/23/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >> >>Pavel Pervov wrote:
> >> >> Geir,
> >> >>
> >> >> What's the first thing we do?
> >> >> I'd suggest switching the build to 1.5.
> >> >>
> >> >> The rest will come shortly :)
> >>
> >> >Now that's a plan! :)
> >
> >
> > Hi Geir,
> > Actually what Pavel says makes sense. Not sure what plan we need. We could
> > do it either way. We can make some changes to the class structure, loader,
> > and the jit/interpreter, and submit a couple of patches. It is not the
> > "huge" patch that you have mentioned .. 7-8 files or so. Or we can switch
> > the build first. This will break drlvm for a short time, and we can
> > submit a
> > couple of bug fixes to get it going again. This way, we will just add the
> > minimum needed for removing the compiler hack. Whatever way you think makes
> > sense.
> > However, you started this thread with saying "no patch over the wall"
> > and making this "learning exercise about DRLVM". Where are you going with
> > this? Do you want to actually enumerate/discuss which source files need to
> > change and in what way, on this thread so that more people can participate?
> >
> > Marginally confused :-)
> > Rana
>
> Just for the record, my goal was to avoid 'moving the goalposts' for
> drlvm to integrate with the classlib and run the tests, apps, etc.
>
> If consensus here is that moving to 5.0 (and thereby delaying that goal)
> is more desirable then I'm happy to go along with it, though I'm keen to
> get the entire end-to-end story working soonest.
>
> Regards,
> Tim
My feeling at the moment is that although drlvm and classlib are working
together[0], it is evident[1] that things are not really integrated.
I would prefer to see "real integration" before we break[0] things by
moving to 5.0.
As Geir pointed out recently, we are not just a Class library project,
so perhaps a change of focus is warranted? Perhaps if we can agree a
set of prerequisite goals (involving our JVMs) for moving to 5.0, we can
... err ... encourage this change of focus?
My prerequisite goals would include things like:
1) Fix the (reasonable) 'hacks' that help us get this far with drlvm
integration - e.g. the static libhyprt.a for instance.[2]
2) Implement enough of the classlibadapter kernel classes such that
JCHEVM will run 'ant rebuild' in classlib[3]. We have some difficult
problems (thread attach) but there is also a lot of low hanging fruit in
terms of missing or incomplete methods.
3) Get drlvm loading with the Harmony launcher from Classlib so we
can have both drlvm and IBM VME around for testing. I think this is
important because it will make it easier for people to test with either
JVM.
4) Change the drlvm build so that its deploy tree layout has no classlib
files in it. So we can do ...
5) Create the top-level build that can combine the trimmed drlvm deploy
tree and the classlib deploy tree to produce a working jdk. (In much
the same way that we currently combine the classlib and IBM VME.)
6) Pull out shared dependencies to top-level so we only need one copy.
At the moment, I think moving to 5.0 would increase the divide between
the JVMs and Classlib.
In the meantime there is still plenty of work to do for those that, for
whatever reasons, don't find these tasks exciting enough - for instance,
the missing java.lang.Character/java.lang.Math methods[4].
Regards,
Mark.
[0] Thanks Geir!
[1] http://issues.apache.org/jira/browse/HARMONY-651
[2] This isn't a criticism; I think these hacks can be justified.
[3] I tried this the other day. It got to the second (non-comment) line
of the first ant script before crashing because ClassLoader.getResources()
isn't implemented yet.
[4] http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony.html#pkg_java_lang
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] Doing the minimum to support Java 5 classfiles
Posted by Tim Ellison <t....@gmail.com>.
Alexey Varlamov wrote:
> Good news: with patches for HARMONY-677, I was able to run 1.5 classes
> on DRLVM + classlib built with target=1.5.
>
> But, I had some fun with the default javac (tried Sun jdk1.5.0_06 and
> jrockit-jdk1.5.0-windows-ia32), which outwits itself in optimizing
> String concatenations.
Alexey, FYI I've applied a workaround to StringBuilder in r423942.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] Doing the minimum to support Java 5 classfiles
Posted by Alexey Varlamov <al...@gmail.com>.
Good news: with patches for HARMONY-677, I was able to run 1.5 classes
on DRLVM + classlib built with target=1.5.
But, I had some fun with the default javac (tried Sun jdk1.5.0_06 and
jrockit-jdk1.5.0-windows-ia32), which outwits itself in optimizing
String concatenations.
At first I got puzzled with this error message:
---------------------------
java/lang/IllegalAccessError : from java/security/Security$1 to
java/lang/AbstractStringBuilder
at java.security.AccessController.doPrivilegedImpl (: -1)
at java.security.AccessController.doPrivileged (: -1)
at java.security.Security.<clinit> (Security.java: 57)
at org.apache.harmony.security.fortress.PolicyUtils$SecurityPropertyAccessor.run
(PolicyUtils.java: 148)
at org.apache.harmony.security.fortress.PolicyUtils$SecurityPropertyAccessor.run
(PolicyUtils.java: 127)
at java.security.AccessController.doPrivilegedImpl (: -1)
at java.security.AccessController.doPrivileged (: -1)
at java.security.Policy.getDefaultProvider (Policy.java: 139)
at java.security.Policy.getAccessiblePolicy (Policy.java: 190)
at java.security.Policy.getPolicy (Policy.java: 131)
at java.lang.ClassLoader.<clinit> (: -1)
at java.lang.Thread.<init> (: -1)
at java.lang.Thread.<init> (: -1)
----------------------------
Indeed, looking at the bytecode of j.s.Security$1:
---------------------
10: invokespecial #4; //Method java/lang/StringBuilder."<init>":()V
13: ldc #5; //String java.home
15: invokestatic #6; //Method
java/lang/System.getProperty:(Ljava/lang/String;)Ljava/lang/String;
18: invokevirtual #7; //Method
java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
< cut off several append() >
49: ldc #11; //String java.security
51: invokevirtual #7; //Method
java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
54: invokevirtual #12; //Method
java/lang/AbstractStringBuilder.toString:()Ljava/lang/String;
----------------------
How do you like the last instruction operand? %)
After some analysis, I figured that the reason was j.l.StringBuilder
extending j.l.AbstractStringBuilder without explicitly overriding
toString(). Interestingly, I tried to reproduce this bug manually, but
in vain...
Eclipse's ecj was smarter (or just less eager :)) and produced correct bytecode.
Neverthless, I guess we have to workaround this in j.l.StringBuilder.
Index: modules/luni/src/main/java/java/lang/StringBuilder.java
============================================================
--- modules/luni/src/main/java/java/lang/StringBuilder.java (revision 417667
)
+++ modules/luni/src/main/java/java/lang/StringBuilder.java (working copy)
@@ -733,4 +733,8 @@
out.writeInt(length());
out.writeObject(getValue());
}
+
+ public String toString() {
+ return super.toString();
+ }
}
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] Doing the minimum to support Java 5 classfiles
Posted by Alexey Varlamov <al...@gmail.com>.
Folks,
I'm back to work, glad to hear all of you :).
Looks like planning and technical directions already settled, I'm
right in time to go coding ;)
Seriously, Pavel Pervov made good observation: very basic v49 support
only includes accepting the version number + groking new LDC
semantics. For the DRLVM, these are several-line-patches for verifier,
interpreter and Jitrino.Jet (well, rather a helper function in VM, as
was pointed by Evgueni).
Recognizing new attributes will be needed no sooner than kernel
classes can exploit them.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] Doing the minimum to support Java 5 classfiles
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Andrey Chernyshev wrote:
> On 6/23/06, Mark Hindess <ma...@googlemail.com> wrote:
>>
>> On 23 June 2006 at 17:10, Tim Ellison <t....@gmail.com> wrote:
>> > Rana Dasgupta wrote:
>> > > On 6/23/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>> > >> >>Pavel Pervov wrote:
>> > >> >> Geir,
>> > >> >>
>> > >> >> What's the first thing we do?
>> > >> >> I'd suggest switching the build to 1.5.
>> > >> >>
>> > >> >> The rest will come shortly :)
>> > >>
>> > >> >Now that's a plan! :)
>> > >
>> > >
>> > > Hi Geir,
>> > > Actually what Pavel says makes sense. Not sure what plan we need.
>> We could
>> > > do it either way. We can make some changes to the class structure,
>> loader,
>> > > and the jit/interpreter, and submit a couple of patches. It is not
>> the
>> > > "huge" patch that you have mentioned .. 7-8 files or so. Or we can
>> switch
>> > > the build first. This will break drlvm for a short time, and we can
>> > > submit a
>> > > couple of bug fixes to get it going again. This way, we will just
>> add the
>> > > minimum needed for removing the compiler hack. Whatever way you
>> think makes
>> > > sense.
>> > > However, you started this thread with saying "no patch over the
>> wall"
>> > > and making this "learning exercise about DRLVM". Where are you
>> going with
>> > > this? Do you want to actually enumerate/discuss which source files
>> need to
>> > > change and in what way, on this thread so that more people can
>> participate?
>> > >
>> > > Marginally confused :-)
>> > > Rana
>> >
>> > Just for the record, my goal was to avoid 'moving the goalposts' for
>> > drlvm to integrate with the classlib and run the tests, apps, etc.
>> >
>> > If consensus here is that moving to 5.0 (and thereby delaying that
>> goal)
>> > is more desirable then I'm happy to go along with it, though I'm
>> keen to
>> > get the entire end-to-end story working soonest.
>> >
>> > Regards,
>> > Tim
>>
>> My feeling at the moment is that although drlvm and classlib are working
>> together[0], it is evident[1] that things are not really integrated.
>> I would prefer to see "real integration" before we break[0] things by
>> moving to 5.0.
>
> I agree the integration doesn't look perfect. On the other hand,
> improving integration and moving to 5.0 could be quite independent.
> Integration issues seem to be mostly related to the building /
> packaging, while 5.0 support would require adding / changing a code.
This is my POV as well. I'm guessing they are independent, at least the
basics for accepting a v5 classfile.
>
>>
>> As Geir pointed out recently, we are not just a Class library project,
>> so perhaps a change of focus is warranted? Perhaps if we can agree a
>> set of prerequisite goals (involving our JVMs) for moving to 5.0, we can
>> ... err ... encourage this change of focus?
>>
>> My prerequisite goals would include things like:
>>
>> 1) Fix the (reasonable) 'hacks' that help us get this far with drlvm
>> integration - e.g. the static libhyprt.a for instance.[2]
>
> It seems libhyprt is needed by VMI module to implement GetPortLibrary
> function.
> I guess static hyprt library is still needed for Windows (this is why
> it was added) while it isn't needed on Linux. The dependency on hyprt
> could be handled more gracefully with <select os="XXX"> tags.
I don't understand why it has to be static.
>
>>
>> 2) Implement enough of the classlibadapter kernel classes such that
>> JCHEVM will run 'ant rebuild' in classlib[3]. We have some difficult
>> problems (thread attach) but there is also a lot of low hanging fruit in
>> terms of missing or incomplete methods.
>>
>> 3) Get drlvm loading with the Harmony launcher from Classlib so we
>> can have both drlvm and IBM VME around for testing. I think this is
>> important because it will make it easier for people to test with either
>> JVM.
>
> Do we want every VM, capable of working with Harmony classlib, be
> started with the Harmony launcher?
No, but ours certainly could.
> It's probably could be too
> restrictive and may require additional work for adopting other VM's
> for classlib.
> However, I completely agree that the non-standard name breaks other
> tools and scripts. Wouldn't it be sufficient just to rename ij->java?
Yes
>
>>
>> 4) Change the drlvm build so that its deploy tree layout has no classlib
>> files in it. So we can do ...
>>
>> 5) Create the top-level build that can combine the trimmed drlvm deploy
>> tree and the classlib deploy tree to produce a working jdk. (In much
>> the same way that we currently combine the classlib and IBM VME.)
>>
>> 6) Pull out shared dependencies to top-level so we only need one copy.
>
> It looks like most of these issues are relating to the building files.
> Geir, would you be willing to work on that, or, someone else could try?
Anyone can try. I have a top-level federation started, and will do more
tomorrow and get that checked in.
What would help is to rip out all the dependency stuff for DRLVM and
just move to a peer directory to DRLVM - the key will be letting us set
'pointers' via properties in the DRLVM build.
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] Doing the minimum to support Java 5 classfiles
Posted by Andrey Chernyshev <a....@gmail.com>.
On 6/23/06, Mark Hindess <ma...@googlemail.com> wrote:
>
> On 23 June 2006 at 17:10, Tim Ellison <t....@gmail.com> wrote:
> > Rana Dasgupta wrote:
> > > On 6/23/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> > >> >>Pavel Pervov wrote:
> > >> >> Geir,
> > >> >>
> > >> >> What's the first thing we do?
> > >> >> I'd suggest switching the build to 1.5.
> > >> >>
> > >> >> The rest will come shortly :)
> > >>
> > >> >Now that's a plan! :)
> > >
> > >
> > > Hi Geir,
> > > Actually what Pavel says makes sense. Not sure what plan we need. We could
> > > do it either way. We can make some changes to the class structure, loader,
> > > and the jit/interpreter, and submit a couple of patches. It is not the
> > > "huge" patch that you have mentioned .. 7-8 files or so. Or we can switch
> > > the build first. This will break drlvm for a short time, and we can
> > > submit a
> > > couple of bug fixes to get it going again. This way, we will just add the
> > > minimum needed for removing the compiler hack. Whatever way you think makes
> > > sense.
> > > However, you started this thread with saying "no patch over the wall"
> > > and making this "learning exercise about DRLVM". Where are you going with
> > > this? Do you want to actually enumerate/discuss which source files need to
> > > change and in what way, on this thread so that more people can participate?
> > >
> > > Marginally confused :-)
> > > Rana
> >
> > Just for the record, my goal was to avoid 'moving the goalposts' for
> > drlvm to integrate with the classlib and run the tests, apps, etc.
> >
> > If consensus here is that moving to 5.0 (and thereby delaying that goal)
> > is more desirable then I'm happy to go along with it, though I'm keen to
> > get the entire end-to-end story working soonest.
> >
> > Regards,
> > Tim
>
> My feeling at the moment is that although drlvm and classlib are working
> together[0], it is evident[1] that things are not really integrated.
> I would prefer to see "real integration" before we break[0] things by
> moving to 5.0.
I agree the integration doesn't look perfect. On the other hand,
improving integration and moving to 5.0 could be quite independent.
Integration issues seem to be mostly related to the building /
packaging, while 5.0 support would require adding / changing a code.
>
> As Geir pointed out recently, we are not just a Class library project,
> so perhaps a change of focus is warranted? Perhaps if we can agree a
> set of prerequisite goals (involving our JVMs) for moving to 5.0, we can
> ... err ... encourage this change of focus?
>
> My prerequisite goals would include things like:
>
> 1) Fix the (reasonable) 'hacks' that help us get this far with drlvm
> integration - e.g. the static libhyprt.a for instance.[2]
It seems libhyprt is needed by VMI module to implement GetPortLibrary function.
I guess static hyprt library is still needed for Windows (this is why
it was added) while it isn't needed on Linux. The dependency on hyprt
could be handled more gracefully with <select os="XXX"> tags.
>
> 2) Implement enough of the classlibadapter kernel classes such that
> JCHEVM will run 'ant rebuild' in classlib[3]. We have some difficult
> problems (thread attach) but there is also a lot of low hanging fruit in
> terms of missing or incomplete methods.
>
> 3) Get drlvm loading with the Harmony launcher from Classlib so we
> can have both drlvm and IBM VME around for testing. I think this is
> important because it will make it easier for people to test with either
> JVM.
Do we want every VM, capable of working with Harmony classlib, be
started with the Harmony launcher? It's probably could be too
restrictive and may require additional work for adopting other VM's
for classlib.
However, I completely agree that the non-standard name breaks other
tools and scripts. Wouldn't it be sufficient just to rename ij->java?
>
> 4) Change the drlvm build so that its deploy tree layout has no classlib
> files in it. So we can do ...
>
> 5) Create the top-level build that can combine the trimmed drlvm deploy
> tree and the classlib deploy tree to produce a working jdk. (In much
> the same way that we currently combine the classlib and IBM VME.)
>
> 6) Pull out shared dependencies to top-level so we only need one copy.
It looks like most of these issues are relating to the building files.
Geir, would you be willing to work on that, or, someone else could try?
Thanks,
Andrey.
>
>
> At the moment, I think moving to 5.0 would increase the divide between
> the JVMs and Classlib.
>
> In the meantime there is still plenty of work to do for those that, for
> whatever reasons, don't find these tasks exciting enough - for instance,
> the missing java.lang.Character/java.lang.Math methods[4].
>
> Regards,
> Mark.
>
> [0] Thanks Geir!
>
> [1] http://issues.apache.org/jira/browse/HARMONY-651
>
> [2] This isn't a criticism; I think these hacks can be justified.
>
> [3] I tried this the other day. It got to the second (non-comment) line
> of the first ant script before crashing because ClassLoader.getResources()
> isn't implemented yet.
>
> [4] http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony.html#pkg_java_lang
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Andrey Chernyshev
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] Doing the minimum to support Java 5 classfiles
Posted by Rana Dasgupta <rd...@gmail.com>.
Several good, sensible comments on things to address in the JVM's fro better
> integration. Specifically for DRLVM, I read them as ...
1. Getting rid of ij.exe :-) and getting DRLVM to be launched by the
Harmony launcher as the IBM VME is done today. Volunteers welcome :-)
2. Better build/deploy integration so that the drlvm deployment directory
has no classlib files in it ...and changing the top level build to be able
to create a jdk out of classlibs + drlvm. I think this is good to do, but
we can start a seperate thread for this..several existing threads have a
little scattered but useful information....and then do it.
3. Removal of the some of the integration hacks eg., static libhyprt.a.
The "[classlibs] hythread implementation" thread is starting to discuss some
of these issues, hopefully that will identify what needs to happen.
For the basic move to Java5 ( which eg., jchevm already supports ), I
would propose that we don't need to wait for the above items to complete,
but start making these code changes now since Evgueni posted a pretty clear
description of what needs to change. If someone is signing up to make any of
these( since this was somewhat the original intention of this thread),
please let this thread know. Would be happy to provide further clarification
as needed. It would be nice to finish this in a week. If there are any
concerns about this approach, please voice them :-)
Thanks,
Rana
RE: [drlvm] Doing the minimum to support Java 5 classfiles
Posted by Nathan Beyer <nb...@kc.rr.com>.
> -----Original Message-----
> From: Mark Hindess [mailto:mark.hindess@googlemail.com]
>
> My feeling at the moment is that although drlvm and classlib are working
> together[0], it is evident[1] that things are not really integrated.
> I would prefer to see "real integration" before we break[0] things by
> moving to 5.0.
>
> As Geir pointed out recently, we are not just a Class library project,
> so perhaps a change of focus is warranted? Perhaps if we can agree a
> set of prerequisite goals (involving our JVMs) for moving to 5.0, we can
> ... err ... encourage this change of focus?
>
> My prerequisite goals would include things like:
>
> 1) Fix the (reasonable) 'hacks' that help us get this far with drlvm
> integration - e.g. the static libhyprt.a for instance.[2]
>
> 2) Implement enough of the classlibadapter kernel classes such that
> JCHEVM will run 'ant rebuild' in classlib[3]. We have some difficult
> problems (thread attach) but there is also a lot of low hanging fruit in
> terms of missing or incomplete methods.
>
> 3) Get drlvm loading with the Harmony launcher from Classlib so we
> can have both drlvm and IBM VME around for testing. I think this is
> important because it will make it easier for people to test with either
> JVM.
Yes please! The 'ij.exe' confused the crap out of me the first time I saw
it. Also, the Eclipse plugin that DRLVM builds doesn't work if you're using
the 1.0.2 version from the snapshots (new version wins out).
>
> 4) Change the drlvm build so that its deploy tree layout has no classlib
> files in it. So we can do ...
>
> 5) Create the top-level build that can combine the trimmed drlvm deploy
> tree and the classlib deploy tree to produce a working jdk. (In much
> the same way that we currently combine the classlib and IBM VME.)
>
I completely agree. Having the IBM VME be just a drop-in after a classlib
build makes it so much easier for class library hackers.
I don't mind flipping the build switch to 5.0 and bumping along with small
increments, but DRLVM needs to be as easy to use as the IBM VME drop in is
first.
> 6) Pull out shared dependencies to top-level so we only need one copy.
>
>
> At the moment, I think moving to 5.0 would increase the divide between
> the JVMs and Classlib.
>
> In the meantime there is still plenty of work to do for those that, for
> whatever reasons, don't find these tasks exciting enough - for instance,
> the missing java.lang.Character/java.lang.Math methods[4].
>
> Regards,
> Mark.
>
> [0] Thanks Geir!
>
> [1] http://issues.apache.org/jira/browse/HARMONY-651
>
> [2] This isn't a criticism; I think these hacks can be justified.
>
> [3] I tried this the other day. It got to the second (non-comment) line
> of the first ant script before crashing because ClassLoader.getResources()
> isn't implemented yet.
>
> [4] http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-
> harmony.html#pkg_java_lang
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org