Re: [drlvm] Doing the minimum to support Java 5 classfiles
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 ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Doing the minimum to support Java 5 classfiles
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Doing the minimum to support Java 5 classfiles
Andrey Chernyshev wrote: On 6/23/06, Mark Hindess [EMAIL PROTECTED] wrote: On 23 June 2006 at 17:10, Tim Ellison [EMAIL PROTECTED] wrote: Rana Dasgupta wrote: On 6/23/06, Geir Magnusson Jr [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional
Re: [drlvm] Doing the minimum to support Java 5 classfiles
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Doing the minimum to support Java 5 classfiles
Besides, verifier code should be updated to support Java 5 changes. On 22/06/06, Rana Dasgupta [EMAIL PROTECTED] wrote: Geir, Not sure at what level of detail you are asking, but we need some changes in the DRLVM class support code to handle the new class format. These include the acc_synthetic , acc_annotation etc. access modifiers, the new attrs like enclosingClass, runtime visible/invisible attrs, signatures for generics support and the class/interface naming convention changes etc. There should be some small changes in the interpreter and JIT to support the ldc CONSTANT_Class . There are possibly some minimal associated changes to the kernel classes also even without the full implementation of annotation, reflection etc. kernel classes as Alexey pointed out on the previous 1.5 thread. Rana On 6/22/06, Tim Ellison [EMAIL PROTECTED] wrote: There are modest changes to the classfile format that need to be supported; once they are in place we can remove the compiler-hack. Regards, Tim Geir Magnusson Jr wrote: It seems we're in general agreement that getting DRLVM to deal with Java 5 classfiles is a good place to start. It supports our project desire to get off the target=jsr14 hack for compiling. So, for those that know the DRLVM codebase, what are the steps? Anyone who throws the One Big Patch over the wall will be summarily beaten about the head and neck with a trout, by the way, and we may not defrost the trout first... lets use this as an exercise to start learning about the DRLVM and get people talking about how to do these things together, with small patches once we agree on the strategy :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best regards, Pavel Rebriy
Re: [drlvm] Doing the minimum to support Java 5 classfiles
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! :) geir Pavel Pervov. Intel Middleware Products Division. On 6/23/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: This sounds easy and fun. What's the first thing we do? geir Rana Dasgupta wrote: Geir, Not sure at what level of detail you are asking, but we need some changes in the DRLVM class support code to handle the new class format. These include the acc_synthetic , acc_annotation etc. access modifiers, the new attrs like enclosingClass, runtime visible/invisible attrs, signatures for generics support and the class/interface naming convention changes etc. There should be some small changes in the interpreter and JIT to support the ldc CONSTANT_Class . There are possibly some minimal associated changes to the kernel classes also even without the full implementation of annotation, reflection etc. kernel classes as Alexey pointed out on the previous 1.5 thread. Rana On 6/22/06, Tim Ellison [EMAIL PROTECTED] wrote: There are modest changes to the classfile format that need to be supported; once they are in place we can remove the compiler-hack. Regards, Tim Geir Magnusson Jr wrote: It seems we're in general agreement that getting DRLVM to deal with Java 5 classfiles is a good place to start. It supports our project desire to get off the target=jsr14 hack for compiling. So, for those that know the DRLVM codebase, what are the steps? Anyone who throws the One Big Patch over the wall will be summarily beaten about the head and neck with a trout, by the way, and we may not defrost the trout first... lets use this as an exercise to start learning about the DRLVM and get people talking about how to do these things together, with small patches once we agree on the strategy :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Doing the minimum to support Java 5 classfiles
I'd suggest switching the build to 1.5. The rest will come shortly :) Now that's a plan! :) Yeah, indeed. :) Seriously speaking, DRLVM is already allowed to load class files with version 49. Certainly, some issues will be brought up while trying to run DRLVM against class library compiled as 5.0 classes (like the one fixed by Gregory Shimansky), but these issues could be then filed as simple JIRAs and fixed accordingly. Am I completely wrong in understanding things? geir Pavel.
Re: [drlvm] Doing the minimum to support Java 5 classfiles
On 6/23/06, Geir Magnusson Jr [EMAIL PROTECTED] 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
Re: [drlvm] Doing the minimum to support Java 5 classfiles
Hello, I can give a little bit more details regarding 1.5 support enabling for DRL VM. As Rana already mentioned there are 8 new attributes should be supported by VM. To be precise there are three common attributes (Signature_attribute, RuntimeVisibleAnnotations_attribute, RuntimeInvisibleAnnotations_attribute) for ClassFile, field_info and method_info. One specific attribute (EnclosingMethod_attribute) for ClassFile. Three additional attributes (RuntimeVisibleParameterAnnotations_attribute, RuntimeInvisibleParameterAnnotations_attribute, AnnotationDefault_attribute) for method_info. And one attirbute (LocalVariableTypeTable_attribute) for Code. All these new attributes should be proccessed in vmcore/src/class_support/Class_File_Loader.cpp file. It seems to be convenient to proccess common attributes in one place. Field::parse, Method::parse and class_parse methods look like the right place for corresponding attributes proccessing.Method::_parse_code method is suitable place to support LocalVariableTypeTable_attribute. New attributes suppport seems to be the most challenging part of 1.5 class format support. A few changes required to basic structures such as Class, Field, Method and ClassMemeber declared in vmcore/includes/Class.h. For example is_varargs() is_bridge() methods should be supported by Method structure, is_enum() by Field and get_signature() by Class_Member. One more feature is left for full 1.5 class file format support. It's ldc opcode. 1.5 extends the scope of this opcode from runtime constant of type int or float and string literals to symbolic references to a class. Thus to support new semantic of the ldc opcode in interpreter mode one need to incorporate required changes into interpreter/src/interpreter.cpp. The only one change for JITRINO.JET compiler is required. Currently the rth_get_lil_ldc_string method which is located in vmcore/src/jit/jit_runtime_support.cpp can load strings only. The implemetation should be extended to load classes as well. Unfortunatelly, I haven't investigated what should be changed in verification proccess for 1.5 class file format support Probably someone else can give us an advice. I hope this inforamtion is helpfull. Open to ansewr your questions. Evgueni - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Doing the minimum to support Java 5 classfiles
Rana Dasgupta wrote: On 6/23/06, Geir Magnusson Jr [EMAIL PROTECTED] 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 -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Doing the minimum to support Java 5 classfiles
On 23 June 2006 at 17:10, Tim Ellison [EMAIL PROTECTED] wrote: Rana Dasgupta wrote: On 6/23/06, Geir Magnusson Jr [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [drlvm] Doing the minimum to support Java 5 classfiles
-Original Message- From: Mark Hindess [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Doing the minimum to support Java 5 classfiles
There are modest changes to the classfile format that need to be supported; once they are in place we can remove the compiler-hack. Regards, Tim Geir Magnusson Jr wrote: It seems we're in general agreement that getting DRLVM to deal with Java 5 classfiles is a good place to start. It supports our project desire to get off the target=jsr14 hack for compiling. So, for those that know the DRLVM codebase, what are the steps? Anyone who throws the One Big Patch over the wall will be summarily beaten about the head and neck with a trout, by the way, and we may not defrost the trout first... lets use this as an exercise to start learning about the DRLVM and get people talking about how to do these things together, with small patches once we agree on the strategy :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Doing the minimum to support Java 5 classfiles
Geir, Not sure at what level of detail you are asking, but we need some changes in the DRLVM class support code to handle the new class format. These include the acc_synthetic , acc_annotation etc. access modifiers, the new attrs like enclosingClass, runtime visible/invisible attrs, signatures for generics support and the class/interface naming convention changes etc. There should be some small changes in the interpreter and JIT to support the ldc CONSTANT_Class . There are possibly some minimal associated changes to the kernel classes also even without the full implementation of annotation, reflection etc. kernel classes as Alexey pointed out on the previous 1.5 thread. Rana On 6/22/06, Tim Ellison [EMAIL PROTECTED] wrote: There are modest changes to the classfile format that need to be supported; once they are in place we can remove the compiler-hack. Regards, Tim Geir Magnusson Jr wrote: It seems we're in general agreement that getting DRLVM to deal with Java 5 classfiles is a good place to start. It supports our project desire to get off the target=jsr14 hack for compiling. So, for those that know the DRLVM codebase, what are the steps? Anyone who throws the One Big Patch over the wall will be summarily beaten about the head and neck with a trout, by the way, and we may not defrost the trout first... lets use this as an exercise to start learning about the DRLVM and get people talking about how to do these things together, with small patches once we agree on the strategy :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Doing the minimum to support Java 5 classfiles
This sounds easy and fun. What's the first thing we do? geir Rana Dasgupta wrote: Geir, Not sure at what level of detail you are asking, but we need some changes in the DRLVM class support code to handle the new class format. These include the acc_synthetic , acc_annotation etc. access modifiers, the new attrs like enclosingClass, runtime visible/invisible attrs, signatures for generics support and the class/interface naming convention changes etc. There should be some small changes in the interpreter and JIT to support the ldc CONSTANT_Class . There are possibly some minimal associated changes to the kernel classes also even without the full implementation of annotation, reflection etc. kernel classes as Alexey pointed out on the previous 1.5 thread. Rana On 6/22/06, Tim Ellison [EMAIL PROTECTED] wrote: There are modest changes to the classfile format that need to be supported; once they are in place we can remove the compiler-hack. Regards, Tim Geir Magnusson Jr wrote: It seems we're in general agreement that getting DRLVM to deal with Java 5 classfiles is a good place to start. It supports our project desire to get off the target=jsr14 hack for compiling. So, for those that know the DRLVM codebase, what are the steps? Anyone who throws the One Big Patch over the wall will be summarily beaten about the head and neck with a trout, by the way, and we may not defrost the trout first... lets use this as an exercise to start learning about the DRLVM and get people talking about how to do these things together, with small patches once we agree on the strategy :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm] Doing the minimum to support Java 5 classfiles
It seems we're in general agreement that getting DRLVM to deal with Java 5 classfiles is a good place to start. It supports our project desire to get off the target=jsr14 hack for compiling. So, for those that know the DRLVM codebase, what are the steps? Anyone who throws the One Big Patch over the wall will be summarily beaten about the head and neck with a trout, by the way, and we may not defrost the trout first... lets use this as an exercise to start learning about the DRLVM and get people talking about how to do these things together, with small patches once we agree on the strategy :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
