Language extensions ?

Thu Mar 27 07:17:00 GMT 2003

>>>>> "Robin" == Robin Garner <robin.garner@iname.com> writes:

Robin> I'd like to ask whether the gcj team is amenable at all to the
Robin> idea of adding some language extensions that would make system
Robin> programming in java possible/easier.
The GCC experience with language extensions in C and C++ seems to be
that they have to be very well defined and very useful to be worth the
maintenance effort. I think any extension would have to have a really
compelling reason, plus documentation explaining it very carefully --
another C/C++ lesson is that underspecified extensions bite us later
on.
Robin> Jikes RVM provides a "magic" mechanism, specifically there is a
Robin> VM_Address class, which looks from a java source point of view
Robin> as an object with a single private int field, with methods for
Robin> doing arithmetic, comparison etc. At runtime, the jit compiler
Robin> intercepts object instances and methods and directly replaces
Robin> them with the appropriate machine code for dealing directly
Robin> with addresses.
How does this interact with the security model?
Robin> Of course in an ahead-of-time compiled environment, I have to
Robin> use int/long directly depending on the address width of the
Robin> target architecture, and use native methods for doing
Robin> type-casts etc.
You can use gnu.gcj.RawData as a system-dependent pointer-sized value.
However you can't really do anything with this value other than pass
it around. It isn't treated like a real pointer; for instance the GC
doesn't examine fields of this type.
I suppose it would be possible to extend RawData to act as a generic
pointer. But it seems like a lot of work, and special cases all over
the place (e.g., the interpreter). Plus, given the existence of CNI,
the gain seems pretty limited.
Robin> I guess another question is whether gcj would be interested in
Robin> using JMTk for memory management ? At the moment there isn't a
Robin> conservative collector (like boehm) in gcj, but is that
Robin> absolutely necessary ?
We still need something that can conservatively scan the stack, since
we don't have any way to annotate the stack (or registers) with type
information. This would require nontrivial compiler changes. Copying
collectors also face a big challenge here.
A mostly-copying collector may work, though I don't think anybody has
tried that with gcj.
Tom