question regarding the java.lang.String design

[Martin Buchholz]

Lots of people have tried to hack on String representation optimizations.
Ken Russell is one of them IIRC.

It's a very hard problem.

My favorite hack would be to always use the "substring optimization",
but the GC has to know about it, and occasionally it would reorg the
internal string representations to avoid "memory leaks" from
small substrings causing large backing arrays to be retained.

Also, compressing String contents is near and dear to my heart.
Any large String that hasn't been accessed for a while could even
be zlib-compressed transparently to the application.
Difficult to make fast and correct.
In principle, it should be similar to the "thin lock" optimization
that expands intrinsic object locks only when needed.

Martin (not a hotspot engineer)

On Fri, Jan 30, 2009 at 10:42, Xiaobin Lu <Xiaobin.Lu at sun.com> wrote:

> Resend the email to hotspot-dev at openjdk.java.net.
> -Xiaobin
>
> Xiaobin Lu wrote:
>
>> Hi folks,
>>
>> While I am looking at the java.lang.String implementation, I noticed that
>> it has "offset" and "count" field in java.lang.String. For the offset field,
>> I only found two places which set that field, but I believe they can be got
>> rid of too. The two places are String(StringBuffer buffer) &
>> String(StringBuilder builder).
>>
>> My question is that if String is immutable, why do we need to carry these
>> two fields? String could be more compacted without these two fields. The
>> equals to method can be more efficiently implemented as just calling
>> java.util.Array.equals(v1, v2) which is intrinsified on x86 at least.
>>
>> Another crazy thought is that we can compact the character array to a byte
>> array if we don't have any characters other than ASCII (which we might use a
>> boolean flag to indicate that).
>>
>> I'd appreciate your insight on this.
>>
>> -Xiaobin
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090130/3fbb7e7b/attachment.html