Patch: MAXPATHLEN usage - PR21821

[Bryce McKinlay]

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
>this too.
>  
>

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?

Bryce