Announcement: micro-libgcj

Fri Jan 6 22:45:00 GMT 2006

On 1/6/06, Joel Dice <dicej@mailsnare.net> wrote:
> 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).
>Yes but generally this can be quite slow.
> >> 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.
>True. Another approach is to add a hidden parent for Object that
internal classes
can inherent from that marks them special. I think that might be cleaner.
I've looked at both. A extra private parent allows the creation of a
new classes not based on java.lang.Object and gets rid of the problem
of modifying java.lang.Object. This approach is more intresting and
if your going to change the compiler adds a lot more flexibility. This
would allow you to add alternatives as replacement for existing java
classes proabably by something as simple as and import change. Plus
the compiler can catch if these objects are used as java.lang Objects.
I think I'll make sure I can support this concept of a hidden super
for Object in my llvm backend probably all I need to do is not get to
tied to the details of Object and allow the super class to be marked
hidden instead of just null for Object.
Mike
> - Joel
>