Null-terminated Unicode strings in java.io on Windows
program.spe at home.pl
Fri Jan 25 18:14:28 UTC 2008
Dnia 25-01-2008, Pt o godzinie 18:54 +0100, Roman Kennke pisze:
> > 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.
More information about the core-libs-dev