John Rose wrote:
> I think the next interesting version of String will mix header and body
> together in a hybrid layout, with private char (or byte) elements and a
> few instance variables at the beginning of the layout.
It would be good to prepare for this by modifying the JNI spec to explicitly
On Nov 11, 2013, at 2:14 PM, Brian Goetz wrote:
> I believe a long time ago it used to work this way; there was a private
> "handoff" constructor in String that StringBuffer would use. Probably got
> changed when we added StringBuilder?
As you might expect, we've been exploring this territor
I believe a long time ago it used to work this way; there was a private
"handoff" constructor in String that StringBuffer would use. Probably got
changed when we added StringBuilder?
On Nov 6, 2013, at 10:54 PM, Robert Stupp wrote:
> Hi,
>
> I was wondering why the mostly allocated class in
On 06/11/2013 21:54, Robert Stupp wrote:
Hi,
I was wondering why the mostly allocated class in nearly all applications is char[]. A deeper
inspection showed that a lot of these char[] allocations are "caused" by the code from
java.lang.StringBuilder.toString(), which created a copy of its inte
On 06/11/2013 21:54, Robert Stupp wrote:
> Wouldn't it worth to try whether passing the
> (Abstract)StringBuilder's value+count values to String results in
> less temporary object creations and therefore reduce pressure on new
> generation (and reduce GC effort)? My idea is to add a field 'shared
Hi,
I was wondering why the mostly allocated class in nearly all applications is
char[]. A deeper inspection showed that a lot of these char[] allocations are
"caused" by the code from java.lang.StringBuilder.toString(), which created a
copy of its internal char array. Most StringBuilder instan
