Patch: MAXPATHLEN usage - PR21821
Thu Jun 2 15:04:00 GMT 2005
Tom Tromey wrote:
>Actually, StringBuilder requires a copy of the data, whereas if you
>use gnu.gcj.runtime.StringBuffer, no copy is made. StringBuilder
>requires a copy since, in the absence of escape analysis, you don't
>know that the user won't reset it and reuse the buffer.
Why couldn't StringBuilder do sharing with copy-on-write, like
java.lang.StringBuffer does? If it did this, any difference between
gnu.gcj.runtine.StringBuffer and StringBuilder would be negligible, and
we could switch to using StringBuilder everywhere.
>Per> For CNI code it would be even better to use a stack-allocated
>Per> "RawStringBuilder" struct:
>When compiling from source, gcj uses gnu.gcj.runtime.StringBuffer to
>implement String concatenation; we could change it to stack allocate
A potential argument against this is that was raised recently is that
stack-allocation creates more work for the GC and increases the chance
of "uninitialized stack holes" where dangling pointers can hide. Without
precise stack scanning, I'm not convinced that the gains would be worth
it compared to potential heap bloat caused by false pointers?
More information about the Java-patches