Announcement: micro-libgcj

[Mike Emmel]

On 1/6/06, Boehm, Hans <hans.boehm@hp.com> wrote:
> > -----Original Message-----
> > From: Mike Emmel [mailto:mike.emmel@gmail.com]
> > > It seems to me that this [no synchronization on arbitrary objects]
> > > will make the implementation far
> > less useful
> > > as a vehicle for running existing Java code, or code you
> > also want to
> > > run on other implementations.  There is lots of code out there that
> > > uses arbitrary Objects for synchronization, e.g. by explicitly
> > > allocating a lock with "new Object()".  And I think code that now
> > > synchronizes on something like strings would need
> > significant changes.
> > > If I got to redesign the language, I might agree with you, at least
> > > with respect to synchronization.  But the cost of such a
> > redesign, in
> > > terms of broken client code, strikes me as huge.
> > >
> > CLDC the VM used in mobile phones removed finalization and
> > added arbitrary differing fixed maximum memory usage limits.
> > So in a sense
> > changes like this have   been done already in standard java. The
> > classes used in cldc are subsetted from the standard java.
> > Not to mention the huge number of buggy and just plain broken
> > implementations that exist today in J2ME.  Considering all
> > the crud you have to deal with using todays "standard"
> > implementations I don't think that modifications to some
> > synchronization code is a huge issue. Plus and added benefit
> > is that a lot of programmers don't actually create new
> > Objects for synchronization but instead use any handy
> > existing object for that purpose. I think that forcing them
> > to actually mark objects that are being used for locking is a
> > good thing and safer then java's current design. And you get
> > smaller faster code.
> >
> I agree that leaving off finalization is OK in this context, especially
> since there is a precedent.  There is some code you cannot practically
> write without it, but that's very rare in any context and extremely rare
> in this one.  And correct uses are still significantly less frequent.
>
True.
> Changing the way synchronization is done strikes me as far more serious,
> and really on a different scale.  Synchronization uses are pervasive
> through a lot of code, presumably even embedded code.  The way that
> standard Java handles it is arguably wrong.  But I'm not convinced that
> implementing the standard Java mechanism is inherently costly in space,
> or otherwise a major problem
> in this context.
>
Generally it has been in the past.  Having synchronization on and
arbitrary object had been a problem and as Joel mentions it can be
made optional. Considering the tight memory constraints of embedded
devices I don't think its a huge issue to leave it of object. Your
often talking about a few kilobytes of code in these cases adapting
the synchronization is not huge and could be a big win. For example I
looked at the cost of traditional  pointer based synchronization for
implementing Dom nodes in java and its pretty bug.

> The libgcj hash synchronization implementation was designed to be no
> slower than using a synchronization pointer, and appreciably faster in
> some common cases.  It was not designed to be as simple or space
> efficient as possible.
> I think an implementation that locks the hash table (or other map
> representation) and avoids all the CAS-based trickery, could be
> significantly simpler, and probably space efficient, though it would
> take longer to acquire or release a lock.  (The original Sun JDK did
> something like this, and I'm not sure if there are patent issues.  I
> doubt it, since I suspect that databases did similar things long
> before.)
>
Yes and the global locking tends to be slow. Thats the problem.
And there is still a space issue with the hash table. I'd think the
best solution for embedded considering space/performance/simplicity is
a pointer in objects
that need a lock. This can be a thin lock design also.

> There seem to be a few (perhaps a bit dubious) cases in which the
> current Java implementation actually allows some idioms that your
> version doesn't.  I think a posting on another mailing list suggested
> implementing named locks by locking interned strings.  I don't think
> that's a good argument for designing that into a language, but it does
> argue again that adapting existing code might not be completely trivial.
>
I don't disagree and as Joel says if it can be made optional thus it
should not a big issue.
In the embedded space having a big bag of tools is important there are
cases where I think having synchronization optional is good and allows
at least a javaish lanaguage to be used instead of C or other
solutions. Having these types of choices
is very useful in the embedded world.   For example many phones have a
maximum on the size of the jar that can be installed so one byte in
the code becomes critically important.
I already mentioned the low  maximum memory constraints. With these
types of constraints a 1k allocation is a big deal.


> Hans
>
>