harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Blewitt" <alex.blew...@gmail.com>
Subject Re: Re: [drlvm] string interning in java
Date Sat, 29 Jul 2006 18:46:48 GMT
On 29/07/06, Salikh Zakirov <Salikh.Zakirov@intel.com> wrote:
> Still, we need to have this functionality, because it is in spec.

True, intern() is part of the spec, and GC-intern() will be much better :-)

> > However, by hard-coding the message like this, you're
> > guaranteeing that the VM will intern() the string "how are you?", even
> > if it never prints this message out (because it's in the constant
> > pool).
> This is not the case, at least for DRLVM (I do not know about other JVMs).
> The string literal in the .java file is compiled to the constant
> pool entry in the class file, and essentially, the whole contents
> of the class file is loaded to memory (native memory).
> No java object instances are created at this point.

The memory (for the message key) is still taking up space in the
constant pool for the class, though as part of the class loading
process. From what I've seen, message keys tend to be longer than the
equivalent field names (also stored in the constant pool). And that's
before the String instance is created.

> We may consider the opportunity to save memory by not keeping the
> class file contents in memory, and loading it on demand, but
> I personally do not know for sure how is it done now.

Neither do I :-) It might only load constants from the constant pool
on demand, but my expectation is that the whole class's contents are
loaded into memory from whatever storage container (e.g. Jar) that
they came from. Perhaps the constants could be optimised in some kinds
of ways e.g. by writing them out to a memory mapped temporary file.

> The java specification does not require eager loading of the string
> literals, and DRLVM in fact does not do it.

Interesting. Perhaps I misunderstood the spec, but I was under the
impression that all String literals were interned like this. Perhaps
it's just because I've seen examples such as:

private static final MESSAGE_HELLO_WORLD_KEY = "hello.world";

which, of course, would be assigned when the class is loaded (and thus
the string literal interned approrpiately). Lazy instantiation of such
keys would delay this behaviour.

> It only keeps space in class file if it is never used.
> Saving space on class loading is a separate issue, not related
> to strings interning.

I think that they are related; but only in that the context of
internationalisation of messages and message keys is often where the
intern() is used (especially with respect to the way message key is
initialised). However, the relationship is not symmetric; it's
possible to discuss intern() without reference to any kind of message

> > Importantly, it explains why the Eclipse NLS class uses static string
> > variables to refer to messages, and not to String literals for exactly
> > this reason. If you use a static string variable that is dynamically
> > initialised from a properties file, you only take the memory up when
> > you need to refer to that message
> actually, I think, this should read "... when you need to refer
> to any of messages contained in the resource bundle ..."

True, the class loading will cause all messages in the same messages
class/file to be loaded at once. (Bundle might be misleading here; an
eclipse bundle/plug-in often has one messages class/file, but may have

> The interned strings design does not precludes from garbage collecting
> interned strings. The patches I've sent in fact do just that.

Yes, this sounds like a good plan.

> > In other words, all of the benefits of intern(), and yet none of the
> > disadvantages. Remind me again why we're not using this method  for
> > doing messages in Harmony?
> The Eclipse approach for localizing messages from java code looks promising,
> but requires some work duplication or complex tooling support.
> As far as I understand, Eclipse approach is completely orthogonal to traditional
> localization approach, so it imposes no restrictions on using two approaches
> simultaneously. Feel free to submit patches to use it :)

Yes, it should be possible to use this too. Eclipse also has tooling
to search for string literals and propose replacements for them
automatically ...


The only issue might be that Eclipse uses an NLS class to do the
in-lining of messages, so we'd either need to re-implement or to
re-use the Eclipse NLS file directly. I think that discussions
following on re: internationalisation should continue in the new
thread created for that purpose.


Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message