Announcement: micro-libgcj

Fri Jan 6 23:46:00 GMT 2006

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