Announcement: micro-libgcj

[Joel Dice]

On Fri, 6 Jan 2006, Mike Emmel wrote:

> YES !!! Its one of the biggest problems with java embedded paying the
> price of supporting synchronization for every object. I think with it
> removed your object header is down to a single pointer right ?

Right.  Note that you get the same effect as far as Object size is 
concerned when enabling HASH_SYNCHRONIZATION in the stock libgcj (it's 
enabled by default).

>> Thus, micro-libgcj is not even intended to be a strict subset of any
>> existing Java standard.  If there is demand for such a subset, or a
>> complete J2ME implementation, micro-libgcj may be a good starting-point.
>> That's not a goal I'm interested in, though.
>>
> Cool I really like what your doing I've no doubt in my mind its the
> right answer for a lot of embedded programming problems. Btw I looked
> at replacing String with a utf8 C pointer. One thing preventing it was
> the syncronization issue. The other was the methods on object. I
> noticed you kept most of the methods of Object even though many are
> empty. Making all the methods of Object final would allow you to
> introduce subclasses of object like my utf8 string pointers that have
> at most a one byte/bit object header that says there really pointers.
> I did not work completly through if the header could be collapsed but
> it would certianly open up the chance to replace objects with
> efficient internal structures if we could ensure that they extend from
> object and object itself has no overridable methods.
>
> Have you considered removing or finalizing the methods of Object ?

I believe this would require modifying the compiler itself, since it makes 
assumptions about the size of Object's vtable.  Until and unless 
micro-libgcj is merged into the GCC repository, I'm not prepared to hack 
the compiler.

  - Joel