[gclist] Java manchines and when to collect.

[Jeremy Fitzhardinge]

Charles Fiterman wrote:
> 
> At 12:33 AM 12/12/97 +1100, you wrote:
> 
> >When people talk about Java chips, I can't really see the need to put
> >the bytecode in hardware, but I wonder what support they're putting in
> >for efficient GC: that's the hard problem.
> 
> Let me explain the advantage and it has nothing to do with performance.
> [idealized view of Java security]

Java's sandbox approach to security is one of the less interesting
things about it, and certainly not essential to the language.  Any Java
implementation must allow access outside the sandbox to be at all
useful; even code within the sandbox must get access to software on the
outside.  A Java chip still needs all the dirty low-level bitbashing
access in there in order to write device drivers.  Even if they're
represented in terms of Java, they're still there.  There's nothing
special about this: CPUs have had distinct user and system modes from
the year dot.  There's also nothing definitively secure about doing it
in hardware, since bugs creep in everywhere.

The type safety aspects of Java are distinct from the sandbox, and are
common to many languages.  Implementing type safety in software is no
special trick: there's nothing very hard about it.  The nice thing about
type-safe languages is that you get to reclaim the MMU hardware for
useful things rather than just being a brick-wall between processes.

Of course, merely having a typesafe language and a sandbox with
constrained accesses doesn't give you security.  Java implementation
have so far completely ignored the problem of denial of service attacks
which are much harder to deal with.  How do you stop an applet from
eating all your memory?  How can you tell how much memory it "owns"
anyway?  What if it convinces something else to allocate memory on its
behalf?

Anyway, back to hardware GC: Java's big problem in memory-constrained
environments is that it always uses GC for memory management, so you
need a GC which can work in such environments.  The announced generation
of Java chips are for embedded applications where you get to spend $5 on
a CPU and it has to run Java; in such environments a Java chip makes
sense.  But if you do only have $5 to spend on a CPU, you've probably
got a memory budget of less than 1MB (or even 512k), so I assumed that
the Java chips have some hardware to make GC in small heap sizes
practical.  I've only ever seen people talk about implementing the
instruction set in hardware, but I haven't seen anything which addresses
memory management.

> Now back to garbage collection and the famous expand or collect
> decision. To make this decision rationally you need to know about
> all storage use on the system. It makes sense to give more space
> to a program until you reach the point of triggering paging. Its
> like a game of black jack where you add points and add points but
> go too far and you lose. A Java machine can have a single heap
> shared by everything.

Paging?  I don't think Java chips will be used in hardware with disks,
let alone VM (and what kind of MMU does it have anyway?).   But you're
right: a system which runs Java all the way down to the hardware
(regardless of its a Java chip or something else with a VM) gets a
number of benefits from unified heap use and efficiencies from
eliminating user->kernel mode switches.

	J