using gcj for a different language - is it possible?

Sat Jan 10 23:11:00 GMT 2004

----- Original Message ----- 
From: "Per Bothner" <per@bothner.com>
To: "Andrew Haley" <aph@redhat.com>
Cc: "Florin" <fmateoc@mfire.com>; <java@gcc.gnu.org>
Sent: Saturday, January 10, 2004 2:51 PM
Subject: Re: using gcj for a different language - is it possible?
> Andrew Haley wrote:
>> > I think the trick used in Smalltalk was to copy and then overwrite
> > both objects with a special indirection object. We could do this in
> > gcj.
>> In the original Smalltalk implementation an "object reference" was
> a 16-bit index into an object table, which pointed to the actual
> objects. (Except for SmallInteger, there could be at most 32768
> object instances in the system!) So becomes: was just a matter of
> swapping the entries in the object table.
>> Later implementations used various tricks - or didn't support becomes:.
> Overwriting an object to add indirection might add extra overhead
> that might be unacceptable.

Well, one of the few situations where become: is traditionally used is for
implementing proxies, but for this usage, faulting in the "real" object that
the proxy stands for would generally far outweigh the time spent performing
the become:.
The other major use case is for dynamically growing collections (by making a
larger instance, then copying the contents, then swapping the object
reference to point to the new object) - this is a particular case where one
does not actually need the full become: semantics, one could implement this
without copy and swap, for example by chaining an additional piece at the
end of object.
> A solution is to also create a special
> indirection vtable that points to "thunk" methods that resolve the
> indirection and then jump to the real methods. Then you only get
> modest overhead for objects that have been objected to becomes:
> without other calls having to check for indirection.
>> There is still an issue with accessing fields (instance variables)
> of indirected objects. Luckily, in SmallTalk you can only access
> fields of the current (this) object, which is never indirected.
>> So it is possible to implement becomes: reasonably efficiently,
> as long as you stick to SmallTalk object, where you can only access
> the fields of the current objects. If you care enough.
> -- 

I do, but I also think it would be just fine even if we were to start with
an inefficient initial implementation.
Thank you,
Florin