- Multiple languages supported, including JS, Java, and Python.
- Good cross-language integration: inheritance, type matching, etc.
- Cross-language debugging, ideally including C++.
- One GC to rule them all, preferably one shared GC, not a super-GC ruling a zoo of heterogenous GCs and reference-counting subsystems.
- Decent JITed performance, because performance matters when you can least afford to rewrite in C++.
- Sandboxed execution security model, type safety, defense in depth.
- Part of a larger open source platform . . .
- . . . that has momentum and excited developers hacking on it.
- A sufficiently open specification process for standardizing and evolving that platform.
- New XML language implementations easy to write, plug in, and demand-load (if we had this today, we would use it for non-web standards such as XForms).
The last item means some number of frozen APIs into the content code, e.g. XTF. SVG and existing XUL and HTML widgets may provide a rich enough rendering vocabulary. If we can mix them well using XBL, then we may not need to expose frozen APIs into layout, gfx, etc.
The goal should be minimal, supportable, and composable high-level APIs, where possible. XBL and XTF point the way.
Back to the more programming-language-specific points above: comments welcome on realistic candidates. Obvious and controversial possibilities include Mono, Java (if open source), and Parrot (last I looked, *way* too Perl6-focused, not very mature, not looking likely to mature quickly).
/be
Choosing a VM is nonsense until a basic decision has been made, that decision is between dynamically typed and statically typed languages for managed code and extensions. To my knowledge, you really can’t have both running with acceptable performance on the same VM (#5).
Your claim that static and dynamic languages can’t perform well in the same runtime is nonsense. See https://ironpython.com/.
/be
Another clue: Rhino (JS implemented in Java) outperforms SpiderMonkey on well-JITed Java VMs.
/be
Hihi, “sufficiently open”, sometimes a few words tell long stories.
re item 10, is an OpenGL widget a valid use case?
(Mind rephrasing that first sentence after the enum? I had to parse it about half a dozen times until I realized what you tried to say.)
Well Java has Jython and Rhino for Python and JS. Lack of decent JVM is probably a bit of a problem, though lots of possible candidates for a Mozilla 2 timeframe. I’ve heard of a Python impl for Mono and I guess there must be a JS impl out there somewhere or maybe Rhino could be ported and Mono seem to have a pretty good CLR impl. I guess it comes down to the politics of the 2 camps.
The main problem for me (as a Java developer trying to learn some XUL) is that theres not any realistic options for implementing low-level components in Java rather then C++ if I need anything not already in the Mozilla platform…
One thing to bear in mind is that Mono *includes* a fully-functional JVM in the form of IKVM, but there’s no JVM or Java application that can run CLI bytecode yet, AFAIK.
In fact, Java is probably the second-most-mature language supported by Mono, because their VB and Ecmascript implementations are still in the early stages, but IKVM is pretty mature. The poor JS support currently in Mono may actually be an issue since Mozilla relies pretty heavily on JS – but then again, who better to improve Mono’s JS support than the people who wrote the language in the first place 😉 Alternatively, IKVM could probably run Rhino (and Jython for python support).
Parrot, AIUI, plans to support both JVM and CLI bytecode, but as Brendan points out, it’s not very mature yet.
Kaffe and gcj seem to be the leading open source Java “VM”s, although gcj forcing the choice between precompiled-native or interpreted may be a problem. I heard that there’s a long-term plan to use some of gcc’s code-generation capabilities to make a JIT for gij, but that seems a long way off.
My personal leaning is towards Mono because it seems to have the best balance of maturity, available languages, and active development. (Sun’s JDK would be a viable competitor if it were licenced acceptably, but since it’s not…). Second choice would be Kaffe, but the fact that Mono supports a strict superset of the languages that any JVM does is hard to argue with.
(On an unrelated note, I regard IronPython as unsubstantiated rumor until the author sees fit to actually release it – I don’t think it’s appropriate to make any decisions based on its performance claims, since they’re totally impossible to verify)
Let us not forget Ruby on that list of languages.
Ruby fans will have to carry the weight, just as Mark Hammond did with PyXPCOM, unless we get Ruby “for free” via a Ruby-capable multi-language runtime.
/be
I’m pretty sure there is already a project out there for that. My point is that if PyXPCom is included then we should have the Ruby version included as well. (hopefully not a *lot* more work – but could create a *lot* more coders).
Carl: you volunteering? No free lunch, and we do not have the committed volunteers and paid hackers to do Ruby in our current plans.
/be
What is the state of https://rbxpcom.mozdev.org/ ?
I never understood how JIT code can be fater than compiled native code. Can you give me a simple explanation, please?
s/fater/faster/
Could Mozilla Suite and Firefox have also spellchecking in HTML form controls like Konqueror 3.2.x?
Ren
Brendan, regarding your post explaining how JIT code can be faster than compiled native code, I have a question for you.
Lets assume a user wants to parse JavaScript in Java. He would go for Rhino. And say there is a CJavaScriptParser in Rhino that would parse JavaScript.
Another user wants to parse JavaScript using C and he uses SpiderMonkey. Which again (say)has an exported ParseJavaScript() function.
By your response, you mean that on a good JIT, the Rhino’s parsing would be faster than SpiderMonkey ?
You also mentioned a JIT for SpiderMonkey’s ByteCode. What is that ? Does it mean that SpiderMonkey actually converts the JavaScript into some form of ByteCode and then parses it ? I am new to the Mozilla code base – hence the question. And you think it would be better if the SpiderMonkey’s ByteCode be Java’s byte code coz there are JITs for it out there. Is that right ?
one word: libjit
https://www.southern-storm.com.au/libjit.html
Hello World,
Here is my comments about Moz 2.0 VM. In fact, it’s some ideas to achieve Moz VM goals. English isn’t my primary language, if sentences are hard to read OR if you don’t get my point… use your imagination! Break your mind’s gate.
7. Part of a larger open source platform…
8. … that has momentum and excited developers hacking on it.
In my opinion, to achieve this we would need an online collaborative development community. What????
An online collaborative development community.
Ok, here are two aspects that will explain briefly this idea.
First, a framework that :
– Can integrate (eventually) all popular OO programming language (C++, Java, Python, C#/VB.Net, php);
– Allows code to be structured in a way that a single object could be developed with more that one language.
– Allows DATA and LOGIC to be separated at the object/class level;
– Allows UI to be created automatically from business objects in a ugly but effective way.
– Allows persistent store creation to be automated for an object; (Object broker)
– Allows developers to create workflow at the Business Logic layer;
– Allows developers to create workflow at the UI layer. Incorporate workflow in XUL..?
– Allows “USERS” and developers to EASILY edit the UI of an application/screen IN the application. (Inherent app functionnality that lt the user modify his UI) This way, developer focus on functionality and UI designers focus on application usability. (By customizing my UI, I create my own UI profile for an application/screen/box
An advanced language group is working on a new VM. It is the Alice sub-group of the Mozart Oz language project.
There’s little public web documentation right now, just a roadmap and a wiki. However, there is real, honest code in CVS, and the thing is coming along. It’s got advanced features. Talk to them! Their cool VM might be just the thing Mozilla is looking for.
# Cross-language debugging, ideally including C++.
See DBGP at https://xdebug.org/docs-dbgp.php
Mono
Pros:
– Easy embedding.
– Open Source 1.0 product with a vision that is inline with mozilla’s goals (see any of Miguel’s or Nat’s discussions on competing with longhorn/avalon)..
– multi language from the ground up (including great support for java) instead of a jvm that gives you really only two options – java or jython.
– the mono culture is certainly very active.
cons:
– some developers are scared of Microsoft. silly but true.
– JS support is not there yet but the path isn’t a long or difficult one.
– Python support is still a bit immature but should be fine by 2.0 timeframe.
– Code Access Security is not complete though it’s certainly getting attention now that embedding it in products like mozilla are on the horizon. But once CAS is implemented, you have rock solid security – much more fine grained and easier to use well than the java sandbox – here’s a good article on it – https://www.codeproject.com/dotnet/UB_CAS_NET.asp
I guess that’s not really a con..
Anyway, my vote is obviously mono..
-Andrew
I’m really fed up with people who are obviosly knowledgeable in their area, and then pop in the middle of discussion and say that the huge JVM limitation is that it supports only one, two or XX languages.
https://flp.cs.tu-berlin.de/~tolk/vmlanguages.html
Also in regard to JIT-ting vs compiling. Actually *sometimes* JIT-ted code could be even faster than the compiled code. It’s called “dynamic optimization” and is relatively new branch of the CS (as opposed to the static optimization which has been going on since the 60’s). Due to the fact that the VM has way more information about your current application, it can perform speculative compilation, given some speculative invariants. Once it finds that the invariant is broken, it could fallback to interpretted code until it compiles in the background a new version of the code. The perspectives for this techonology are are huge, and Sun’s HotSpot compiler is still only scratching the surface. (https://tinyurl.com/5udz6)
Of course, there’s no free lunch. The current JVM’s are memory bound (vs CPU bound.) There are a lot of other factors that could influence the decision and I in no way say that the JVM is the right solution for Mozilla (in fact I think that the people overhype the multilanguage argument, so IMHO Mozilla would be better off with some high quality lean and mean virtual machine [which might be even Mono, but I haven’t had experience with it].)
I didn’t write this post to propose solution, but to put straight the guys that say “that product has a talking paperclip and that’s why it is ahead of all the competition”
well, there go my 2c
I should add that the data security and the sandbox isolation (when there are more applications using the same VM, which seems to be the case with Mozlla) is much more important then the superficial convenience of coding in 10 languages at once. In this regard, JVM offere:
– policies – a way to enable or disable basic operations (like access to local files)
– class file verification – checking the bytecode for compliance – since there’s no “unsafe mode”, this gives 100% guarantee that the class would not corrupt the internal structures of the VM.
– class loaders – object created from class loader X has no way to access object created from classloader Y unles someone hands it to him. (this provides a foundation for writing secure sandboxed applications)
I guess that the .Net runtimes have also some support of these features, but so far nobody commented on that.
Andrew,
Thank you for the article. I found it really interesting.
I agree with most of the things you say. I still disagree about the importance of the multilanguage argument. And BTW yes, you can extend classes between the languages as long as they can be compiled to bytecode (and most of them can be.)
Still my point is that it needs thorough analysis before mozilla commits to any VM (and I didn’t see Parrot anywhere so far, though it’s very promising and has the advantage that it is OS and for sure will stay OS.)
Since Brendan already stated the main requirements, for Java I could say that:
1. Multiple languages supported, including JS, Java, and Python.
Yes
2. Good cross-language integration: inheritance, type matching, etc.
Yes for all languages compiling to bytecode. The bad point is that for integration with native languages you have to use JVM and here the things get hairy.
3. Cross-language debugging, ideally including C++.
Possible, but currently not available. Look for more projects implementing JSR45.
4. One GC to rule them all, preferably one shared GC, not a super-GC ruling a zoo of heterogenous GCs and reference-counting subsystems.
Yes, especially with the improvements in the upcoming 1.5
5. Decent JITed performance, because performance matters when you can least afford to rewrite in C++.
Yes
6. Sandboxed execution security model, type safety, defense in depth.
Yes, proven in practice.
7. Part of a larger open source platform…
No
8. … that has momentum and excited developers hacking on it.
Yes, though if you look at the projects – fairly large part of them are web and persistance frameworks…
9. A sufficiently open specification process for standardizing and evolving that platform.
JCP, controlled by Sun. Individuals and companies can still participate – look at Apache.
10. New XML language implementations easy to write, plug in, and demand-load (if we had this today, we would use it for non-web standards such as XForms).
Not sure what this means in the context of a VM. You could always write a front end that interpretes arbitrary syntax into bytecode, also you can download/generate executable code at runtime.. If this counts – the answer is yes.
That’s it, now someone should do the same for the CLR and for Parrot.
cheers,
Dimiter
Sorry, I should learn to proofread my posts *before* I click “post”..
2. Good cross-language integration: inheritance, type matching, etc.
Yes for all languages compiling to bytecode. The bad point is that for integration with native languages you have to use *JNI* and here the things get hairy.
I’d like to comment on the posts about SpiderMonkey performance versus Rhino.
Recently I ported some massive XSLT+JS apps of mine from Xalan+Rhino+SunsJVM1.3 to libXslt+SpiderMonkey. I did this in persue for greater speed. Both running on HP-UX11.
The result was that there was _almost_no_ difference in exec time between them (expect starting time and some memory consumption) and this after -O2/9 compile optimizations.
This could be due to specifics in SpiderMonkey implementation, I don’t know. Still I’m surprised of what HotSpot vm is doing.
niki