Announcement: micro-libgcj

[Boehm, Hans]

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

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.

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

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.

Hans