Stuart Ballard wrote:
> John Keiser wrote:
> >
> > >From: "Jochen Hoenicke" <[EMAIL PROTECTED]>
> > >
> > >As I currently think of writing my own JVM I have thought a bit about
> > >bootstrap isssues. Before I can call a java method like
> > >String.intern(), I have to link and initialize that class and probably
> > >many others like java.util.Hashtable, some io classes (look in
> > >String.<clinit>), etc. When linking a class I have to resolve the
> > >constant pool. And while resolving the constant pool I have to create
> > >interned Strings. This is the chicken and egg problem.
> > >
> > >I would rather make String.intern() native for this reason.
> > >
> >
> > OK, I can see your guys's reasoning there, it makes sense. How about if we
> > move it to the VM interface (so that it would be VMString.intern())?
> >
> > Brian, what are your thoughts? I have a couple of hours free Saturday, so I
> > can take care of this.
>
> I was under the impression that this problem went away automatically if
> the VM follows the full specification... how is Japhar able to handle
> this issue with no problems? I remember it coming up but I don't
> remember there being any problems once the relevant sections of the VM
> spec were implemented...
>
> If this is true, I don't see a reason to make it part of the VM
> interface - having it the way it is provides an incentive for VM writers
> to fully follow the spec, even in its more complex areas.
>
> Stuart.
As far as I can tell, Vojta wants to take Strings in the constant pool and
intern() them so that different classes point to the same String object (to save
memory). I dimly remember this from the spec. Perhaps Japhar simply does not
perform this specific operation?
The intern() behavior is specified in the VM spec, section 2.3: 'String literals
and, more generally, strings that are the values of constant expressions are
"interned" so as to share unique instances, using the method String.intern.'
The problem he is running into is made clear by the following set of events:
1. String.<clinit>() (initialize String class)
2. private static Hashtable internTable = new Hashtable()
3. Hashtable.<clinit>() (initialize Hashtable class)
4. Resolve constant String(s), including "loadFactor" (which
happens to be the first one)
5. new String()
6. String()
7. intern()
8! intern() tries to use internTable, but that won't be
created til step 9!
9. Hashtable()
Note step 9. This is where it actually fails, because internTable hasn't been
created yet--it was on its way to being created when intern() was invoked!
I cannot figure out how we could implement intern() in Java without the system
running in circles, unless we drastically changed Hashtable or making intern()
rather inefficient ... do you have any suggestions?
--John
