Null-terminated Unicode strings in java.io on Windows
roman at kennke.org
Fri Jan 25 17:54:01 UTC 2008
> Please observe:
> 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...
More information about the core-libs-dev