Comments on: Hacking on java.lang.String

By: Steve

Steve — Thu, 20 Mar 2008 11:53:15 +0000

Interesting and creative idea but I don’t think it would work. I think arrays rely on special bytecode instructions for setting and getting it’s indexed fields instead of methods.

By: peter lawrey

peter lawrey — Thu, 20 Mar 2008 09:37:10 +0000

I take your point re: different JDKs. You could have changes between versions of the same JDK.
The approach I have taken to writing ASM code is to write basically what I want in Java, use the ASMifier to dump the code required and generalise it.

{: Its occurred to me you could override Object to change the behaviour of primitive arrays. :}

By: Scott

Scott — Thu, 20 Mar 2008 04:20:50 +0000

@Peter – thanks for the comment and link. Yes, yours is a much more straightforward way to accomplish the same thing. At Terracotta it made sense to use ASM since we are already doing quite a lot of dynamic bytecode instrumentation (we have to in order to cluster any arbitrary client code) and have a framework for it. ASM makes it straightforward to, say, intercept field-level reads of “value” char[] field and route them through our __tc_getvalue() method, although you can certainly code that by hand. Also, our dynamic bootjar generation shields the users from slight variations of String source code in sun, ibm and azul JDKs.

By: Peter Lawrey

Peter Lawrey — Wed, 19 Mar 2008 22:08:56 +0000

I like ASM and the idea of dynamic instrumentation however I believe in this case a simpler approach would be to just create a customised version of the String class and use that.

The linked example compresses Strings longer than 1024 characters.
http://www.freshvanilla.org:8080/display/www/Compressing+java.lang.String

The included unit test outputs
String of length=38890 uses 18527 bytes.

By: Scott

Scott — Tue, 18 Mar 2008 23:53:56 +0000

@Tim – good points, and it would probably take me (or better yet one of my smarter teammates) at least an entire post to properly address them all. But a couple things: the optimizations I’m talking about in this blog are more concerned with conserving heap space on a cluster (L1) node. Imagine a clustered Map cache with large String values (say, XML documents). The heaps of all L1 nodes are impacted by a large String cache. With these optimizations, even though each L1 node takes a CPU hit each time it compresses a String, the tradeoff is less heap usage for all L1 nodes (assuming each L1 nodes doesn’t need to access every single value in the clustered cache). And of course this is all configurable – you can turn String compression on/off and set the String size at which it kicks in. So you could say we’re tackling use cases where the L1 heap is the bottleneck. It’s definitely a balancing act, and one that we are continuing to test and profile.

By: Steve

Steve — Tue, 18 Mar 2008 23:34:51 +0000

The short answer is depends.

If one is using large strings then it doesn’t take long before the network is the bottleneck. Also, having the strings compressed means less processing by the server, less GC on the server and less data to write to disk. Another advantage of doing the compression on the client is that actually, the client is rarely CPU bound and has horsepower to spare. Another cool thing about this approach is that nodes that receive the compressed strings may never have to decompress them or not have to decompress them for some time saving considerable memory. Keep in mind that it is important to only compress strings over a certain size and that size is configurable. In the future we may also do tricks like proxifying strings.

By: Tim

Tim — Tue, 18 Mar 2008 22:24:26 +0000

I’ve looked at String compression before to speed up network communications. It seems that unless the network is a significant bottleneck, the added cost of CPU cycles invalidates the benefits gained by the compression.

In short, doesn’t compressing kill your scalability due to CPU loads? The network is not usually the bottleneck.

By: Guy

Guy — Sun, 16 Mar 2008 06:12:10 +0000

Thanks that would be great, I’m trying to build a monitoring system that required this capability.
And I couldn’t find a way to instrument the classes that were loaded before my javaagent.

By: Scott

Scott — Sun, 16 Mar 2008 03:07:45 +0000

@Guy – as soon as time permits I’d like to write a whole nother post about just what Terracotta’s dso-java process does, including how instrumentation happens during Class loading. Stay tuned

By: Guy

Guy — Sat, 15 Mar 2008 22:33:13 +0000

Can you extend more on how you were able to instrument java.lang.String?