[gclist] Garbage collection and XML

[David Chase]

This is not about garbage collection at all, unless we want
to grumble about the design decisions underlying some of these
things.

At 09:39 AM 3/7/2001 -0500, Ken Anderson wrote:
>At 11:57 PM 3/6/2001 , David Chase wrote:
>>final public class U {
>>   public static String u(String s) { return new String(s.intern()); }
>
>Unfortunately, the String() constructor copies the underlying char[].
>I think this will work the way you intended.
>
>final public class U {
>  public static String u(String s) { return s.intern(); }}

Nope, we're both wrong.  Richard O'Keefe was looking for a
way to get space-saving, but not-eq, equal strings.  You're
right about the String constructor, but it turns out that there
IS a way:

  s.intern().substring(0)

That will first intern s, to ensure sharing, then create
a new String object that shares storage with the interned
String, but is not == to it.

Regarding Hans's observations about gcj -- if they want to
roll their own String class, that's fine, but if they intend
to interoperate with native code (JNI code), they'll need
to use the same String data structures, field names, and types
as Sun uses for their classes.  I learned this the hard
way. 

Hans is regrettably correct about the effects of "every-object-
is-a-lock".  Though this has led to some really impressive
innovation in lock implementation technology, it mucks up sharing,
and anyone who actually wants to make a system that is robust
in the face of denial-of-service attacks (there are some cute
ones involving locking) has to create their own private Objects
for locking anyhow.  If you DO want to take advantage of sharing,
you can't lock on those objects either, since you can never
keep track of who's got what lock when/where, so again there's
no use for EOiaL.  It's kind of a useless feature, but there
it is.

David Chase