Regardless if its a patent or not, what is being described here doesn't seem to be infringing on the patent anyway.
See the first Claim #1:
PART1 <storing a device-independent intermediate representation of a source code; > and PART2 < in the event an indication is received that the source code has changed, using the changed source code to generate and store a new intermediate representation of the changed source code.>
If I understood correctly, only thing you would be doing is the PART1 hence you are NOT infridging on the patent.
IMHO Disclaimer= not a lawyer, dont follow any advice you see here ;-P
It is ridiculous.
It is a general compilation process, applying it to these specific conditions is in no way technically original. I hope it isn't from a legal standpoint, but IANAL...
"Consistent performance. (not like the V8 engine pausing the whole application for GC)"
Static complication doesn't get you out of having to worry about memory management. What's the alternative here? Reference counting? Leaking everything? Using a subset of JS that doesn't allocate anything? All of these things come with considerable costs.
Your skepticism is very justified, however - I would like to see the various existing GC benchmarks and GC latency benchmarks working with no pauses, to believe this.
If the same code in V8 is causing a pause to deal with GC, then the LLVM compiled code must be doing something different to handle the memory. Is it using a different GC? Is it running on a different thread? Is it just sucking up memory without freeing it?
These are all things that need to be known before getting too excited about the speed of LLVM compiled Javascript.
The next step would be to swap out the existing Javascript runtimes with this frontend plus a sandboxed backend for the native platform so they can compile Javascript to LLVM bytecode, then to native code.
Finally, you add an extension to the <script> tag to allow loading arbitrary LLVM bytecode, something like <script src="http://some/url/code.llvm" type="text/llvm">.
Once that's in place then you'd be able to execute any language that has an LLVM front end inside the browser environment. Javascript is no longer the sole language of the web, and things like Emscripten and asm.js become obsolete.
http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437...
Running arbitrary LLVM bitcode would make browser exploits trivial, unless you ran the bitcode in a sandboxed subprocess. PNaCl's sandboxing is much lighter weight than requiring IPC to interact with the browser.
EDIT: Just realized this is mostly redundant with another reply, but hopefully gives a bit more detail for those not interested in following links.
Also there's Smalltalk/X: http://www.exept.de/en/products/smalltalkx
libart for Android also brings AOT to a jitted/VMed language.
Objective C is not a dynamic language.
Do not confuse dynamic language with dynamic typing or whatever the standard wisdom in the Apple cult is.
And, it is very easy to beat existing engines on small new benchmarks. Much harder to win on larger, more varied benchmarks, and much harder still to win on real-world codebases.
But, the project is existing nonetheless, looking forward to see more information on it.
Write a game once in JS/WebGL. People can play it through the browser on the desktop, or download an app on Android/iOS/BB10/whatever that is the same code compiled with JXCore/LLVM for native performance and/or offline play.
Best of both world really. Especially with things out there like CoffeeScript, LLJS, and Typescript, which make using JS as your dev language manageable even for us traditional OO-heavy game devs.
> - Consistent performance.
> (not like the V8 engine pausing the whole application for GC)
But... you're still going to need garbage collection, unless you are only planning on supporting something like ASM.js. So there will still be application pauses for GC.
Also, you mention that you have support for JavaScript OO, but I notice the benchmarks don't exercise programmer-defined JavaScript objects/prototypes. Do you have numbers on its OO performance, or is that still something you're working on?
Finally, how do you handle type inference at the LLVM level? I assume you implemented some form of JIT compilation? I'd be interested to hear more!
This is not accurate, and shows a lack of respect for the JS VM developers at other browser vendors.
Very close to the time v8 was launched, SquirrelFish Extreme from Apple and TraceMonkey from Mozilla were also launched, each far faster than previous JS VMs, beat v8 on various benchmarks while losing on others, etc.
Since then v8 has generally been in the lead, certainly, but not always, and it would depend on the benchmark and platform.
So it is not fair to say - and this is not the first time I see it, or else I would not write this comment - that v8 is single-handedly responsible for JS being fast today.
