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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath