[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: java.lang.Class patches
Re: java.lang.Class patches
01 Mar 2003 17:56:40 +0100
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.
- Re: java.lang.Class patches,
Mark Wielaard <=