4 ms·

Hasn't anyone ported zygote over to desktop Linux/Windows? You just keep the preconfigured jvm process running and fork it indefinitely for each new process. Yo

by yason 14y ago

Hasn't anyone ported zygote over to desktop Linux/Windows? You just keep the preconfigured jvm process running and fork it indefinitely for each new process. You'd still suffer some overhead depending on each application but that's just expected anyway. The jvm startup overhead isn't.

ansible 14y ago
The Dalvik VM does run on x86 now... You'd just need to convert all your .jars and that's it. I haven't heard of any other incompatibilities with standard Java. Edit: Is there a port of Dalvik to amd64? A cursory search did not find one.
- eropple 14y ago
  I don't know if such a port exists, but I do know that I wouldn't want one. Dalvik's performance characteristics are scary-bad and there are plenty of incompatibilities with Java libraries that do any sort of weaving or code generation (so you still can't use Groovy, Rhino, etc.).
  - ansible 14y ago
    ... and there are plenty of incompatibilities with Java libraries that do any sort of weaving or code generation ... Ah, good to know. I've mostly just had to bring in things like a database library, and in one case LuaJ. None of those did need to do bytecode generation.
    - eropple 14y ago
      Yeah, for that you'll be fine, but take Rhino for example - Rhino offers, through LiveConnect, the ability to create JavaScript objects, at runtime, that satisfy Java interfaces. Which is cool, and useful for a lot of stuff. But the version of Rhino you can use on Dalvik has all of the bytecode generation disabled (obviously) and as a consequence, it can't emit the necessary bytecode to create the interface-fulfilling Java wrapper to make the JS object do what you want. It's generally bogus. Also it's really hard to express how much slower Dalvik is than HotSpot in the general case, too. It seems faster with the Android 4.2 version (by about 30%, in my highly unofficial testing) but it's still pretty agonizingly slow.
bdonlan 14y ago
forking tends not to work very well if you're running multiple threads, as Java tends to do.

by yason 14y ago

ansible 14y ago

The Dalvik VM does run on x86 now... You'd just need to convert all your .jars and that's it. I haven't heard of any other incompatibilities with standard Java. Edit: Is there a port of Dalvik to amd64? A cursory search did not find one.

eropple 14y ago
I don't know if such a port exists, but I do know that I wouldn't want one. Dalvik's performance characteristics are scary-bad and there are plenty of incompatibilities with Java libraries that do any sort of weaving or code generation (so you still can't use Groovy, Rhino, etc.).
- ansible 14y ago
  ... and there are plenty of incompatibilities with Java libraries that do any sort of weaving or code generation ... Ah, good to know. I've mostly just had to bring in things like a database library, and in one case LuaJ. None of those did need to do bytecode generation.
  - eropple 14y ago
    Yeah, for that you'll be fine, but take Rhino for example - Rhino offers, through LiveConnect, the ability to create JavaScript objects, at runtime, that satisfy Java interfaces. Which is cool, and useful for a lot of stuff. But the version of Rhino you can use on Dalvik has all of the bytecode generation disabled (obviously) and as a consequence, it can't emit the necessary bytecode to create the interface-fulfilling Java wrapper to make the JS object do what you want. It's generally bogus. Also it's really hard to express how much slower Dalvik is than HotSpot in the general case, too. It seems faster with the Android 4.2 version (by about 30%, in my highly unofficial testing) but it's still pretty agonizingly slow.

bdonlan 14y ago

forking tends not to work very well if you're running multiple threads, as Java tends to do.