[geeks] Browser licensing?
Alois Hammer
aloishammer at casearmour.net
Wed Sep 3 19:29:49 CDT 2008
On Wed, 3 Sep 2008 18:39:59 -0400, "Joshua Boyd" <jdboyd at jdboyd.net>
said:
>
> Why must instansing a new VM be slow? How is it impossible for someone
> to figure out how to do it quickly?
Not exactly the first questioner here or elsewhere, but I'll answer
here: after working with what I'm *fairly* sure is every type of VM
anyone's ever thought of coding, the top losers are JIT VMs. Every JVM,
.NET VM (is there a contraction for that one?) and any other JIT VM I've
been near has been slow to load, eats lots of RAM, tends to perform one
limited task, occasionally runs away and takes a core with it (until
killed, if you can kill it), tends to be running code that wasn't
designed with any kind of useful IPC in mind (not that that's the VM's
fault, precisely), is almost always running single-threaded code (sort
of a staple of VM design), and has a history of being reasonably easy to
break out of, security-wise. Sure, Java can be nice and fast *once the
VM's running*, but it's usually not, and that's beside the point for
most JavaScript performance cases.
So far, every job I've been in, on, or near for most of the last decade
has required daily interaction with Java apps, and now I'm starting to
be forced into interacting with .NET. Not only that, but most of those
apps would have been vastly better off if they'd been coded by people
with experience in C, or the willingness to learn C (or whatever)
instead of writing every trivial app in Java. My absolute worst case so
far is a C&C system for voice recog apps whose UI was Java, and
instantiated an *entire new JVM* for every remote app server you wanted
to perform a batch function on. It ran on P3 desktops with 128MB and
Win2K. The incompetent developers insisted it wouldn't run on anything
other than J2SE 1.4.1 (1.5 had had a couple point releases, and 1.4.2
had been out a while). It didn't take long to get people to understand
that asking it to control more than two or four app servers at a time
was, reward-wise, sort of like hocking a loogie against a stiff wind.
The entire thing's job was to send a few strings to open TCP ports on
machines with fixed IPs. I could have used netcat and written a shell
script in a few lines; more if I hardcoded all the app servers.
Maybe I'll be spectacularly wrong and V8 will be the first JIT VM I've
ever heard of that doesn't grab absurd amounts of system resources to
perform moderately trivial tasks (and, hey, minimum one per JS-executing
tab, too), but I'll be fairly shocked if Google's subcontractors are the
first people to manage it. Sun's only been trying for... a decade and a
half? More? Virtual machines as an implemented concept goes back to
1967, and reality is as terrible now as it was then, except that this
time we supposedly have virtualisation instruction sets in our CPUs that
are supposed to somehow make these things faster, and never seem to.
More information about the geeks
mailing list