Null-terminated Unicode strings in java.io on Windows

[Roman Kennke]

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).

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

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

Cheers, Roman

-- 
http://kennke.org/blog/