Null-terminated Unicode strings in java.io on Windows

[Krzysztof Żelechowski]

Dnia 25-01-2008, Pt o godzinie 18:54 +0100, Roman Kennke pisze:
> Hi,
> 
> > Please observe: 
> > 
> > 1. 
> > the amount of memory needed to manage the allocation 
> > is greater than the number of bytes 
> > needed to store one additional character, 
> > so the relative impact on memory usage will not be dramatic.
> 
> This is just ridiculous. An average Java app has tons of Strings in
> them, most of which are _not_ used in GetStringChars. Allocating one
> additional jchar for each String surely _does_ impact. Especially on
> embedded systems (this is where I'm working on).

I never said there will be no impact.

Aside: wouldn't it be cheaper if the device worked without Java on it?  
(another ridiculous question, I am afraid)

> 
> > 2. The string usually has much more characters then one.
> > That means, if strings take 10 characters on the average, 
> > the overhead is 10%, in the impossible worst case, as explained below.
> > This is an overhead I (and most programmers) can live with.
> 
> Yeah, but not in the embedded/mobile world.

Well, in that case it seems a fork is needed.
The desktop code can assume that string buffers are z-term.
The mobile code has to copy.

> 
> > 3. Memory is allocated in chunks.  
> > The size and alignment of the chunk is subject to various limitations.
> > If the characters of the string do not fill the chunk entirely, 
> > there is good chance 
> > that there will space for the terminating zero anyway.
> 
> Yeah, and if not? I can only speak for Jamaica, where memory is
> allocated in chunks of 32 bytes, or 16 chars. There's a 1 out 16
> (actually, 2 out of 16 because of some internal stuff) chance that
> there's no trailing space for the zero, so should we allocate another
> 32bytes, only to get this zero termination for a JNI method that's only
> rarely used? So much for the no-impact statement above...

So that accumulated memory cost is linear in the numer of strings?  
Good point, statement 3 is invalid.

Chris