Re: Classpath build process and VM-specific issues

[Archie Cobbs]

Jeroen Frijters wrote:
> > I admit not to have looked into or thought about java.lang.ref support
> > yet. How many VMs based on GNU Classpath properly implement those?
>
> I have a (sort of) working implementation. I had to replace
> java.lang.ref.Reference (and I use instanceof to detect PhantomReference
> (all the others are implemented the same :-()).

I am also working on reference support in JC and have not needed
to modify the java.lang.ref classes at all.

> I think that in this case (contrary to Class - VMClass) it makes sense
> for everyone to have a VMMethod instance, because Method contains state
> (the setAccessible flag). Does everyone agree with this, or are there
> good reasons not to have a VMMethod instance?

Hmmm.. In JC each Method instance has a private vmData field of type
byte[] containing a pointer to the internal struct _jc_method.
My copies of the reflection classes are different from Classpath's
(there are no VMFoo classes) for various reasons so I guess my
opinion isn't relevant. But in any case for these reasons "no"
I don't agree :-)

I would be interested in a quick poll of VM implementors using Classpath:
do you care more about having fewer diffs with "stock" Classpath or
modifying & optimizing your VM's core classes to eke out optimal
performance?

Implementors of the former type would vote "yes" for these kind of changes
while implementors of the latter would vote "no" (as they only serve to
add more diff headaches at the next merge).

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com