Overall, we’ve designed WebVM to have the minimum performance impact possible. There are three areas where performance might be a concern:

VM startup time and impact on page load time

We don’t usually start the VM when the page/plugin are first loaded; the VM is started when it is first needed, which is the first time a javascript method is called on the plugin. This way the VM startup should not affect page load times. (Note that there is a way of forcing the VM to start immediately if required.)

Method call overhead

The code paths involved in method invocation and all parameter conversion are optimised as much as possible, with the minimum of object creation in java. If a method call only passes primitive types (eg ints or doubles) then no garbage is created in java. All java methods that are the target of javascript calls are referenced directly by the plugin so there is no dynamic lookup for method resolution as there would be in liveconnect, for example.

Memory consumption overhead

There is a certain amount of heap memory needed to start the VM. We try to keep this to a minimum. It is kept small by two main methods:

• the Java VM does not start the Lcdui or include any graphics system. Therefore there are no buffers for images, canvas, etc. Usually it is these buffers that take up a significant proportion of the heap requirement when running a MIDlet;

• multiple WebVM instances execute within the same VM. Instances on the same web page (or from the same domain) execute in the same isolate, so you do not get a duplicate heap overhead of each WebVM instance you create.