using gcj for a different language - is it possible?
Tom Tromey
tromey@redhat.com
Mon Jan 5 19:40:00 GMT 2004
>>>>> "Florin" == Florin <fmateoc@mfire.com> writes:
Florin> I have been toying with the idea of getting Smalltalk compiled
Florin> ahead of time like Java is (when compiled with gcj).
Florin> Now, the base class libraries being substantially different, I
Florin> was wondering if it is possible to use gcj without the base
Florin> classes implementations from libgcj, and reading instead all
Florin> the base classes from class files, therefore String or
Florin> Exception for example ending up in a different place in the
Florin> class hierarchy.
This isn't really possible. You could try to accomplish it, but it
isn't clear it is worth the effort. Java compilers in general know a
fair amount about the class library. I'd say there are 15-20 classes
known to the compiler in one way or another.
I think there are a few plausible choices open to you.
One is to put the Smalltalk class library into a package in the Java
namespace. E.g., "com.mfire.fmateoc.smalltalk". Then you can
transform Smalltalk code directly to Java code (or bytecode) and avoid
any gcj hacks.
Another choice is to make it possible for the gcj and smalltalk
runtimes to inhabit a single address space. I.e., ensure that the
various low-level parts of the two runtimes can be shared: a common
view of threads, files, garbage collection, etc; but otherwise having
separate type and object universes (perhaps with some sort of bridge,
I dunno). I'm idly interested in seeing things evolve this way.
Florin> because in Smalltalk handling an exception does not
Florin> necessarily unwind the stack, the operation triggering the
Florin> exception may (for example) be retried with a different
Florin> argument.
This is likely to present real problems for you, since I don't think
gcc's underlying exception handling mechanism is prepared to deal with
a situation like this. Perhaps you can do it by generating
complicated exception handlers, I don't know.
Florin> Given that there are no interfaces in Smalltalk,
Florin> all the interfaces in the system would only mean "implementing
Florin> a certain selector", so the bad cast exception would map
Florin> perfectly to Smalltalk's runtime generated
Florin> MessageNotUnderstood. The question is, could the compiler do
Florin> my work for me, or should I try to help it by first doing some
Florin> type inferencing?
The compiler should handle this for you. We also don't know how gcj
will react to having thousands of interfaces. Perhaps not well.
Florin> 3. One significant difference in the Smalltalk object model is
Florin> that classes are real objects that in turn have their own
Florin> class and dynamically looked-up methods. Is it possible for
Florin> the object type information to point to another object? I
Florin> would prefer to avoid modifying the object layout, which is
Florin> probably known to the garbage collector. Alternatively, I
Florin> could add an instance variable to Object pointing to the class
Florin> object, but that seems heavy-handed and would be disconnected
Florin> from the type information.
In Java each Object has a class represented by an object of type Class.
However, Class is final, so you can't extend it to do anything other
than what it already does.
This sounds like the kind of thing you would add to your own
"smalltalk.Object" class (the hypothetical base class in your
hierarchy).
Florin> There are probably more issues that I missed, but one other
Florin> thing that I remember right now is: does gcj support weak
Florin> references ?
Yes.
Tom
More information about the Java
mailing list