RVM

Update JikesRVM copies of classes (e.g. Constructor) to match the 1.5/current Classpath API

Details

  • Number of attachments :
    2

Description

JikesRVM maintains its own versions of a few classes, such as java.lang.reflect.Constructor. On implementing the JMX extensions, I noticed that some of the method signatures have fallen behind those in Classpath and the Java API. For example, many now take variable arguments where JikesRVM's version still expects an Object array. Maybe we should also setup a JAPI run against the JikesRVM version of the API to catch such things?

  1. rvm-268-01.diff
    12/Mar/08 5:35 PM
    1 kB
    Andrew John Hughes
  2. rvm-268-02.diff
    12/Mar/08 5:36 PM
    1 kB
    Andrew John Hughes

Issue Links

Activity

Hide
Ian Rogers added a comment -

Ideally we want to stop having Jikes RVM copies of classes. This may mean we need to refactor code in Classpath to use VM interfaces to things (rather than assuming a native implementation). We should probably do this across the board, even for things like java.lang.Class.

Show
Ian Rogers added a comment - Ideally we want to stop having Jikes RVM copies of classes. This may mean we need to refactor code in Classpath to use VM interfaces to things (rather than assuming a native implementation). We should probably do this across the board, even for things like java.lang.Class.
Hide
Andrew John Hughes added a comment -

Well Constructor is a VM class in its entirety, as are some of the other reflection classes:

classpath/vm/reference/java/lang/reflect/Field.java
classpath/vm/reference/java/lang/reflect/Constructor.java
classpath/vm/reference/java/lang/reflect/Method.java

So what we're actually saying is should part of these be in Classpath itself? Because at the moment the VM is responsible for implementing them wholesale, but can use the reference versions as a template.

Show
Andrew John Hughes added a comment - Well Constructor is a VM class in its entirety, as are some of the other reflection classes: classpath/vm/reference/java/lang/reflect/Field.java classpath/vm/reference/java/lang/reflect/Constructor.java classpath/vm/reference/java/lang/reflect/Method.java So what we're actually saying is should part of these be in Classpath itself? Because at the moment the VM is responsible for implementing them wholesale, but can use the reference versions as a template.
Hide
David Grove added a comment -

Personally, I think is makes sense for the reflection classes to be VM classes entirely. By the time you pull all the VM specific stuff out of there, there would be very little of interest left.

If it's easy, it would be useful to do a one-off JAPI run against Jikes RVM to catch places that we need to fix. I'm not sure if it's worth setting up an automated JAPI run since we should only be talking about a dozen or so classes that are slowly changing.

Show
David Grove added a comment - Personally, I think is makes sense for the reflection classes to be VM classes entirely. By the time you pull all the VM specific stuff out of there, there would be very little of interest left. If it's easy, it would be useful to do a one-off JAPI run against Jikes RVM to catch places that we need to fix. I'm not sure if it's worth setting up an automated JAPI run since we should only be talking about a dozen or so classes that are slowly changing.
Hide
Andrew John Hughes added a comment -

It should be trivial to add this to builder now it is doing JAPI runs again. All I need is to create the appropriate JAPI file for JikesRVM (statically for now, until we can get JikesRVM building on Classpath again and put it on builder).
RVM-364 held me up the other night, because I can't seem to even get a clean workspace to build with IcedTea anymore. I do a fresh checkout of trunk tonight and try with that.

Show
Andrew John Hughes added a comment - It should be trivial to add this to builder now it is doing JAPI runs again. All I need is to create the appropriate JAPI file for JikesRVM (statically for now, until we can get JikesRVM building on Classpath again and put it on builder). RVM-364 held me up the other night, because I can't seem to even get a clean workspace to build with IcedTea anymore. I do a fresh checkout of trunk tonight and try with that.
Hide
Andrew John Hughes added a comment -
Show
Andrew John Hughes added a comment - JAPI run now active: http://builder.classpath.org/japi/classpath-jikesrvm.html
Hide
Ian Rogers added a comment -

r13953 fixes a few of the broken APIs. To fix java.lang.Class is more work, especially as we implement the code in Java and conveying that type system properties like this is a superclass of that are hard to argue in the source code. It may even be a case of having to resort to VM magic to keep the type system happy.

It would be nice to re-run JAPI to see the result with the low hanging fruit gone.

Show
Ian Rogers added a comment - r13953 fixes a few of the broken APIs. To fix java.lang.Class is more work, especially as we implement the code in Java and conveying that type system properties like this is a superclass of that are hard to argue in the source code. It may even be a case of having to resort to VM magic to keep the type system happy. It would be nice to re-run JAPI to see the result with the low hanging fruit gone.
Hide
Andrew John Hughes added a comment -

Use Classpath's Constructor, Field and Method solves many of these JAPI errors.

Show
Andrew John Hughes added a comment - Use Classpath's Constructor, Field and Method solves many of these JAPI errors.
Hide
Andrew John Hughes added a comment -

Committing a couple more fixes.

Show
Andrew John Hughes added a comment - Committing a couple more fixes.
Hide
Andrew John Hughes added a comment -

Fix method types in java.lang.Class

Show
Andrew John Hughes added a comment - Fix method types in java.lang.Class
Hide
Andrew John Hughes added a comment -

Add Class.isSynthetic() and Class.isAnnotation()

Show
Andrew John Hughes added a comment - Add Class.isSynthetic() and Class.isAnnotation()
Hide
Ian Rogers added a comment -

r14210 did a small change to bring java.lang.Class closer to Classpath's by using vararg notations. We should make sure we do this elsewhere.

I just wanted to note I have a conflicting patch that changes VMMethod, etc. not to have a back link to Method. Instead when the Method is required it is passed as an extra argument. It is only required in Method.invoke and similar methods, so this isn't a big overhead, but my change significantly improves constant propagation.

Show
Ian Rogers added a comment - r14210 did a small change to bring java.lang.Class closer to Classpath's by using vararg notations. We should make sure we do this elsewhere. I just wanted to note I have a conflicting patch that changes VMMethod, etc. not to have a back link to Method. Instead when the Method is required it is passed as an extra argument. It is only required in Method.invoke and similar methods, so this isn't a big overhead, but my change significantly improves constant propagation.
Hide
David Grove added a comment -

Defer to 3.1.1

Show
David Grove added a comment - Defer to 3.1.1
Hide
David Grove added a comment -

bulk defer open issues to 3.1.2

Show
David Grove added a comment - bulk defer open issues to 3.1.2
Hide
Andrew John Hughes added a comment -

http://builder.classpath.org/japi/classpath-jikesrvm.html#err_missing_java_lang needs a new JikesRVM build to compare against, but I only see one method relating to this java.lang.Class#asSubclass.

Show
Andrew John Hughes added a comment - http://builder.classpath.org/japi/classpath-jikesrvm.html#err_missing_java_lang needs a new JikesRVM build to compare against, but I only see one method relating to this java.lang.Class#asSubclass.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated: