using gcj for a different language - is it possible?

[Tom Tromey]

>>>>> "Florin" == Florin  <fmateoc@mfire.com> writes:

Florin> I am afraid of what the performance would be like if Smalltalk
Florin> literals would become non-base classes. After all, the major
Florin> itch that I am trying to scratch here is performance.

I don't know Smalltalk, but I assume you are talking about something
like unboxed literals, like you'd see in a typical Lisp
implementation?

Modifying gcj to support something like that would probably be
super-hard.  It isn't really set up to deal with something like tagged
pointers and literals at all.  You'd need to modify gcj, g++ and
probably parts of the runtime as well.

If you just mean having a Smalltalk class not be a subclass of
java.lang.Object, really the overhead isn't that high.  Though as I
say, I don't know Smalltalk, maybe any overhead here is too much.

>> 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> Could you please elaborate a little more?

Well, the idea is to share the lower-level bits of the runtime.  So
we'd have a single cross-platform view of threads, share the garbage
collector, share libffi.

This way we'd share some maintenance costs.  (At least, assuming this
sharing makes sense in actual fact... sometimes needs are different
enough to cancel out the cost-sharing.)

This would also lay the groundwork for letting Smalltalk code and
gcj-compiled Java code co-exist in the same process.  The next (major)
step would be to have some way to communicate between the two
runtimes.

Like I said, I'm idly interested in this sort of thing.  I'd like to
see someone try to write a kind of "reverse IKVM", where Mono (gasp)
and libgcj co-exist in a single runtime, but without requiring the
Java bytecodes to be translated.  That way we could still interoperate
but not lose the performance benefits of gcj.

Florin> Are the two runtimes (gcj and Objective-C) similar/related?
Florin> Is there any bridge between the two?

As far as I know nobody has done any work in this area.  I don't know
Objective-C either, so I can't really offer a guess at how difficult
this would be.

Florin> Does gcj use the Java static type information for
Florin> optimizations (inlining)?

Offhand I don't remember what sort of inlining we can do.  We're sort
of moving away from doing inlining by default, since that breaks
binary compatibility.  But, yes, if the user asks for it, gcj will
inline methods, hopefully even across class boundaries.

Tom