Re: File.lastModified *extremely* slow ?

From: John C. Bollinger (jobollin_at_indiana.edu)
Date: 09/01/04 

Date: Wed, 01 Sep 2004 10:18:59 -0500

Chris Uppal wrote:

> John C. Bollinger wrote:
>
>>I will therefore have to retrench, and say that when
>>you intern() a String you *may* ensure that a copy is retained for the
>>remainder of the VM's lifetime. Whether or not that is is in fact
>>ensured depends on the String implementation [not on the VM
>>implementation, as the JW article's author mistakenly implied].
>
>
> It certainly doesn't /depend/ on the JVMs implementation. I think the author's
> reasoning was (or rather, should have been ;-) that in the specific JVM he was
> testing, String interning /is/ done by the JVM -- in the discussion afterwards
> he talks of the interned String data being kept outside the heap.

He certainly seemed to imply that the VM was the responsible agent, and
I continue to disagree. There was a question in the discussion that
appeared to get at this point, but which was not interpreted in that light.

He did claim in the discussion that interned String data is kept outside
the heap. Inasmuch as that behavior is neither required nor forbidden
by Java, I have to take issue with his blanket statement to that effect.
  It may be true of many -- or even all -- existing JVM / platform
library implementations, but one cannot assume that it will be so.

> Incidentally, I can't see the sense of that implementation decision: either the
> implementation is simple-minded and does not reclaim interned Strings, in which
> case it makes sense to keep the data in a special non-GCable area outside the
> heap; or it does reclaim them, in which case the sensible approach is to use a
> weak collection (or perhaps just the JVM's underpinnings for weak collection)
> and it would be pointless to store them anywhere except the heap -- which is,
> after all, designed for that kind of thing.

I agree, and I suspect that Sun's current implementation is an artifact.
  It appears that their earlier VMs really didn't ever reclaim interned
Strings, and thus it would have made sense to keep the pool outside of
the heap. When they changed that, they may have done a less thorough
redesign than they ought to have done.

> Changing the subject slightly. It's not completely clear to me that it is
> legal for the JVM to recycle interned Strings in this way -- at least not it if
> has observable consequences (other than not-running-out-of-memory ;-) and
> System.identityHash() is certainly observable. The contract of intern() is
> perhaps not strong enough to rule this optimisation out for "normal" strings
> (and in any case, I'm not sure that the JavaDocs are normative). However the
> contract in the JLS2 for the String literals does not (IMO) leave any scope for
> /any/ observable recycling of the corresponding objects -- the language is
> unambiguous and repeated. What's more the interning of Sting literals is
> discussed (briefly) in the context of class loading, so it would not be easy to
> argue that the JLS writers had just "forgotten" this issue.

I agree again. I wonder whether the part that was forgotten was
System.identityHashCode(); I can't think of any other way to observe the
effect. I'm not string on JNI, though; could there be a way to figure
it out from the native side?

> The obvious (and preferable, IMO) fix would be to weaken the language of the
> JLS in its next edition. Alternatively, the implementation could "pin"
> interned Strings when their identityHash() is evaluated, and make them
> non-recyclable at that time (say by adding a strong ref to the String to some
> internal list).

When you're right, Chris, you're right. Once again I agree.

> As it stands (and despite the article's assertion) I don't see any reason to be
> confident that:
>
> class Oddity
> {
> static final int aHash = System.identityHash("Hello");
> static bool check() { return aHash == System.identityHash("Hello"); }
> }
>
> cannot false from Oddity.check().

I'm not sure I follow. I know you're aware of the requirements of the
JLS, in particular: "Literal strings within the same class (§8) in the
same package (§7) represent references to the same String object
(§4.3.1)." Are you suggesting that common VMs may be non-compliant on
this point, or that "same object" should be interpreted differently in
the context of that statement (JLS 2ed, 3.10.5) than elsewhere in the JLS?

John Bollinger
jobollin@indiana.edu

Relevant Pages

  • Re: ActionEvent Performance Issue
    ... Java does not prevent the "same" interned String from ... Since == compares object references, not the contents of the string, ... value as .equals() when .equalsitself returns the results you need ...
    (comp.lang.java.gui)
  • Re: How string literal is working
    ... The compiler takes care of it. ... String s1= new String ... The first let s reference an interned String. ...
    (comp.lang.java.programmer)
  • Re: C# Fundamentals Part 3: ReferenceEquals question
    ... Both x and y are initialzed to an empty string, ... itself is an interned string. ... The result is that x and y are references to ... reference to any other interned string using "new" - and it actually ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Why String is Immutable?
    ... > That makes a String and then converts is to a StringBuffer ... it take the interned String in the constant pool and creates a ... > it just makes Java code more painful and boring to read. ...
    (comp.lang.java.programmer)
  • Re: << Security bulletin 04-006 WINS security issue [yup that affects us pretty much]
    ... Microsoft ASN.1 Library Bit String Heap Corruption ... To demonstrate this vulnerability, all that's necessary is a constructed ... If the function that called ASN1BERDecLength() then attempts to ...
    (microsoft.public.backoffice.smallbiz)