Henry Minsky:
> It is my understanding that the current deployed KVM in the IAppli phones
> does not have garbage collection implemented at all.
Ouch.
> The IAppli API is optimized to not allocate garbage for things like UI
events,
> but it's still hard to write a moderately complex program which doesn't
> generate any garbage at all, if it dynamically generates Strings, because
> String in Java is a write-once object. You can kludge with character
> arrays, but they are not universally
> supported by all the API functions.
How annoying. You mean there's not even something as dumb as
"collect anything with a zero reference count"? This would seem to take
care of most ongoing String residue....of course, it also means
maintaining reference counts, which is computational overhead,
and hard to optimize out in general.....
> I have heard the next generation of Java phones will have a working GC,
> they just
> didn't have room in these ones to fit it in.
GC itself need not be a huge memory hog - even the Sussman/Steele MIT Scheme
chip of yore implemented it with a few mark bits for each datum and a
smidgen of
microcode for the mark/sweep algorithm. Yeah, when you get up to
generation-
scavenging on-the-fly compactifying blah blah etc., it can get pretty hairy.
But that's
code, not data, and ROM is cheap. So I have to wonder if space was really
the
consideration here.
Possible DoCoMo sideways step: special-case String to be reference-counted,
and
require destructors (a la C++) for all other objects. If Sun starts saying
"Hey, that's
not 100% Pure-as-the-driven-snow Java," DoCoMo can pull a Microsoft on
them -
"Java?...hmm, yes, iAppli code certainly resembles Java, doesn't it? But
also C#,
come to think of it...."
-m
leap@gol.com
[ Did you check the archives? http://www.appelsiini.net/keitai-l/ ]
Received on Tue Apr 24 07:33:23 2001