viernes, 5 de septiembre de 2008

Copy-on-write optimization for StringBuilder and StringBuffer

Hoy he publicado mi primer post en el foro "General performance Discussion" @java.net:

http://forums.java.net/jive/thread.jspa?messageID=297309

Forums @ java.net
Pego directamente (en inglés, me ha costado lo mío, je je):
Hello everybody.

The old 1.4 version of StringBuffer had a very nice implementation of a "copy-on-write" (COW), [as have the C++ String and the .NET StringBuilder, I think]. In few words: when the toString() method is called, it doesn't copy the char array to the String, but shares it with the String and marks as "shared" inside; and if there are future call to insert or remove or others in the "immutable" section of the char array, then creates a copy of the array and goes on (so the String keep immutable and the StringB can mute.

For some reason, this changed in JDK 1.5, becoming in a "always copy" strategy. Why? Haven't find it. I have only found the forum entry dated in 2005:
http://forums.java.net/jive/thread.jspa?messageID=29032.

I don't understand what kind of concurrency problem that the COW approximation has. Can someone put the light on me?

For testing, I have hacked AbstractBuilder, StringBuilder and StringBuffer with the COW hack. And in a microbenchmark there is a significant boost in both cases, also NetBeans, Glassfish, my J2EE apps and so on worked great with this patch. Sorry but no deep multithreading testing...

Why not reintroducing it in JDK 7? No API changes, cheap change, and a good boost.

Salvo que tenga unos problemas rarísimos que mi corta mente no llega a alcanzar, no veo por qué no... al fin y al cabo StringBuilder es thread-unsafe de por si, y StringBuffer... bueno, si funcionaba el COW en versiones anteriores del JDK no veo la diferencia (a no ser que no fuera realmente thread-safe, claro :-)

Por espacio, no pego el código de AbstractBuilder, StringBuilder y StringBuffer que he tocado, es algo distinto al 1.4 pero el concepto es el mismo...

Hilos (para el que tenga interés en los detalles concretos, de momento podéis revisar ambos hilos): Actualización - 05/09/2008:
Parece más un problema de consumo de memoria que de sincronización. Entiendo perfectamente el tema (puede verse en la Bug Database, bugs 4259569, 4724129, 4524848, 4910256), pero es una auténtica pena por el acelerón que supondría. Así que en el foro he propuesto combinar esta opción con -XX:+AggressiveOpts. Seguremos informando...


No hay comentarios: