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
