Re: using gcj for a different language - is it possible?

["Florin" <fmateoc at mfire dot com>]

----- Original Message ----- 
From: "Tom Tromey" <tromey@redhat.com>
To: "Florin" <fmateoc@mfire.com>
Cc: <java@gcc.gnu.org>
Sent: Thursday, January 08, 2004 3:12 PM
Subject: Re: using gcj for a different language - is it possible?


> >>>>> "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.


Indeed Smalltalk's SmallIntegers and Characters are implemented as tagged
pointers, but I was not really hoping to keep them that way. And if they get
translated to primitive types, there should be no performance lost. I was
thinking more about String and Symbol (interned String) literals, as well as
literal arrays (similar to Java's array initializers).


> >> 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.)


I don't know yet how the runtime is organized and built. I guess I will
understand better after I start reading the code. But yes, I was certainly
hoping to share some of the maintenance cost.

> 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.

This sounds interesting to me too. And I would also be interested in C#
interoperability.

> 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.

I'll try to see, maybe I can reuse some things from the Objective-C runtime.

> 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.

You mean for dynamically loaded classes? Well, not all applications use this
facility, but whoever compiles the application should know if this will
happen or not, and should have the possibility to take advantage of this
extra knowledge.

> But, yes, if the user asks for it, gcj will
> inline methods, hopefully even across class boundaries.
>

Somewhat related, is there a switch (or has it been considered) for
informing the compiler that an application is not multi-threaded? I suspect
the performance gains could be significant, especially for Java, with all
its synchronized methods.

Thank you for your help,

Florin