[geeks] Browser licensing?

[Joshua Boyd]

On Thu, Sep 04, 2008 at 12:54:44AM -0400, Alois Hammer wrote:

> That's true; I haven't really explained why.  All I can do is leave it
> at, "My long experience leads me to run screaming into the night when
> people talk about putting things in VMs."  Or possibly, "If no one else
> has managed it since 1967, why is Google going to be the first?"

I wonder how many people have raelly tried to do this, and what
constraints were they focussing on.  Hotspot server is slow to start,
but then it isn't meant to be constantly stopped and restarted, so why
should they have focussed their efforts on that?  Strongtalk is the
fastest for what it is, and plenty of slower smalltalk systems are still
more than fast enough for most things, and particularly do not have to
be sluggish.
 
> And, yes, I'm concerned about startup performance.  If V8 manages to run
> big JS apps really, really fast after the JIT or dynarec or whatever you
> like is finished, that's good news for Google apps.  It's terrible news
> for the little snippets of JS that make up a lot of the tiny web
> applets, forms, UI frameworks and whatnot that I tend to encounter
> *instead* of Google apps.  And, if you're using Firefox at all, do
> remember that Firefox and some of the add-ons use JS for themselves.

It is entirely possible to have a VM that is both a JIT and a bytecode
interpreter.  Presuming that your bytecode is denser than machine code,
this is even desirable because it lets you compile the heavily used
functions, but reduce the memory taken up by lesser used paths to
improve the chance that they are cached.  

It is even possible to keep runtime counters and demote a compiled
function down to bytecode if it ceases to be called often enough.  You
could also have the bytecode->machine code translator running as a
seperate thread.

> Since you'd like me to talk about VM startup by itself: uncached JVM
> (Sun J2SE 1.6u7) instantiation runs to about eight to nine seconds on
> this Linux workstation with an Intel E8400 and 4GB of RAM.  (Sun, if
> you're reading, this would be an excellent time to *stop* compiling
> against libstdc++-v3.  I don't use it any more, and neither should you. 
> Also, xcb support would be appreciated.)  Let's be overly generous and
> assume that V8 would only take... oh, two seconds to instantiate.  Why
> would I want to wait two extra seconds for a common JS applet to get
> rolling when Firefox 3.01 executes it inside a fraction of a second
> (with Greasemonkey, NoScript, and several other add-ons interfering with
> the execution) and uses far less RAM to do it?

The actual startup speed of JVM or .NET have no relevent here as they
clearly aren't trying hard to start quickly, nor do they show you the
entire possible range of ways for a VM to start.

It seems to me that just because startup tends to be slow, who says that
every process needs to actually perform a clean startup?  Why not
initialize a clean tab template (including the VM) on initial startup,
then immediately after the fork, the new process jumps into the clean
already initialized template?  This should only take as long as the fork
would take for the memory size of the manager process. 

Now, you can either do a clean startup on the launch of Chrome, or you
could even stash the template for a clean VM back to disk after the
initial startup (I don't know about specifically doing this for VMs, but
stashing the initialized structures back to disk as a blob is a common
way to accelerate starts in the future, and I'd be surprised if certain
industries that use VMs and need quick load performance don't do this,
specifically the video game industry, who could very well want a fresh
VM for each level).
 
> Straight-up, brutal honesty: with V8 and Gears(r) Inside(tm), Google
> Chrome was obviously written to make Google's services look better
> and/or run faster and, hey, let you browse most of the rest of the web
> without having to start another browser.  It was *not* written to make
> *everyone's* pages load faster and run faster.  That's the entire
> purpose of WebKit's SquirrelFish, which Google explicitly note having
> removed in their comic^wbrochure.

Obviously the proof will be in the testing of Chrome, both now and in
the future as they more from 0.2 to 1.0.

On a side note, I do have the V8 source here, and I really wish it had
documentation at the top of each file.   One of the things I do see is
that they have ARM support already.  Also, I see in one spot they use
the magic number #DEADFACE.  I don't think I've ever seen that one
before.  Another thing I see is that they have snapshots of some sort.

Also, while I mention the posibility of compiling to bytecode first
before going to machine code and executing a mixture, that is not what
V8 does.  It always executes machine code.  It looks like that to the
extent that it regenerates machine code, it is in response to the
properties of an object changing, putting in optimizing accessors once
it knows what method to use.

They also talk about creating hidden classes, even though Javascript
doesn't have classes.  I believe that same wizardry was pulled for the
Self language at Sun previously.