Re: java.lang.Class patches

[Mark Wielaard]

Hi,

On Fri, 2003-02-28 at 06:26, Archie Cobbs wrote:
> Below is a subset of my current set of diffs for java.lang.Class.
> I'm sending them just for anyone to look at and for consideration
> for checking in. I think some of them could be useful for classpath.
> I'd be interested to hear what other people think.

Nice. Thanks. You make a lot of good observations about our VM interface
policies which make me think how to do it better.

> Notes about this patch...
> 
>   - The 'vmData' field is VM specific, ignore that part.
>     A neat idea stolen from SableVM.

If you want to make this more generic then we might want to introduce a
real "VMData" type (a bit like libgcj has its RawData type. It looks
like a normal type, but "normal" code should never touch it (maybe only
to pass it to VM specific methods.

>   - The Class.initialize() method is from SableVM and I like it
>     a lot as it simplifies the work that the JVM has to do for class
>     initialization.  Since initialization is a one time thing it's
>     less important if things are slower. The integer thread ID might
>     need to be generalized to long or byte[] or something.

I would split this (and the native stepX() methods) out into a VMClass
helper class specific to your VM.

>   - Is the Class.forName() patch correct?? I just uncommented
>     the code that was already there but commented out.

Yes, that is how it should work. As a side note: The JikesRVM developers
asked to have a VM dependent VMSecurityManager.getCurrentClassLoader()
which might be (much) more efficient in this case. gcj also has such a
getCurrentClassLoader() method so I think we should do this
(See patch #1031).

>   - getComponentType() became native, this is probably VM specific.
>     Seems like an obvious and easy native method though.

This is another method that I would push into a VMClass helper and keep
the non-native version in Classpath. That makes it easy for VM
implementors to get something working quickly, but which they can
override if they wish for efficiency.

>   - Several of the get*Field*(), get*Method*(), and get*Constructor()
>     methods became non-native. This may make them slower (?) but for me
>     it's worth it because it saves a lot of work in the VM.

I think the tradeoff is nice because it makes clear what a VM
implementor must implemeent (the native*() methods) which makes it just
work. But that they can also override the complete method fi they think
it can be done more efficiently.

Class is a interesting, ehe, class since VMs might want to do a lot of
optimizing for it which makes splitting it into a general Class and
VMClass part interesting.

Cheers,

Mark