nanogui: MicroWindows, Java and desktop
Subject:
Re: MicroWindows, Java and desktop
From:
####@####.####
Date:
3 Mar 2000 20:58:24 -0000
Message-Id: <m12QypE-000dcpC@debian>
It might be a little off-topic, but I'd just like to mention one more aspect
of Java in small devices, one which has been forgotten by almost everybody.
If you look in an operating system or computer architectures book, you'll
see that modern microprocessors devote an awful lot of transistors and
switching events to providing the abstraction of virtual memory. Think of it
this way: with each memory access, the processor has to look up in a
translation table to convert each logical address to a physical address. It's
quite amazing that you can do it without burning up much of your memory
bandwidth. Never mind the problems that virtual memory causes for designing
cache systems.
Also, operating systems pay a high price in the time it takes to tear down
and put up memory protection walls while context switching. All that burns up
CPU cycles, time, and ultimately battery power in small devices.
Although most people like Java either because they think it's a nice language
(I do, but I've got plenty of friends who don't) and I think there are a lot
of people who like Java because it's trendy. The real technological
innovation of Java, however, is the way the JVM provides memory protection
in ~software~ with very little cost: the verifier does a static safety check,
and then the code can be interpreted or translated with only a handful of
runtime safety checks -- just array bounds checking and null pointer testing.
Java Card is the most beautiful application of this technology yet. It makes
possible something the smart card industry has wanted for years: a
multiple-applications smart card. Certainly it would be nice to load multiple
applications on a smart card, but it's also necessary to make sure you can't
load an application which steals the private keys out of another application.
There just aren't enough transistors on a smart card for hardware memory
protection, and more conventional methods of software memory protection would
have too great of a performance cost.
Java would come into it's own in small devices that are based on RISC
processors without virtual memory and with lightweight operating systems, say
exokernel based, that use Java's memory protection for safety. It's an
interesting vision, but we're already buying small devices with hardware
memory protection and we're already running Linux on them, so it might never
materialize.
