Re: Classpath build process and VM-specific issues

[Archie Cobbs]

Andrew Haley wrote:
>  > Finally, "RawData as opaque
>  > pointer" doesn't require any unwraping but does hit GC cycle time
>  > severely as every object has to be check for being in this special
>  > RawData class. So for JC byte[] is best.
> 
> We get away with this in GCJ because a pointer outside the heap is
> ignored.  I would have thought that many other GCs do this too.

They probably do, but JC doesn't right now.. it assumes objects live
either in the heap or in per-loader memory, and in the latter case,
it assumes the object must be a Class instance. Relaxing these assumptions
wouldn't cost that much, but the point is of course that there would
be a non-zero impact so the change wouldn't be "free".

In the future JC may support stack-allocated objects, in which case
it would then know to ignore any reference pointing to a "weird" place,
so this will probably change.

As I've stated before, there are lots of different tradeoffs with
all the VM's out there and IMHO Classpath should not try to assume
too much about what's efficient, how things "should" be done, etc.
but rather specific a fairly generic way of doing things and let
the VM implementors do their VM-specific tweaks, as they are surely
going to have to do anyway.

-Archie

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