1. Why wouldnt this Flash-JIT, fit in a JVM for example? Or CLI? Depending on system of course.
Lack of demand? There's no real use for Flash, outside of specialized applications, most of which are web browsers, and there are plenty of other languages to use in a CLI, or on the JVM.
2. If Flash has a nice JIT compiler, just as the JVM or analog for CLI, why couldnt adobes version perform just as good ? (- and I guess it could, with the same billions of dollars invested into it as java or c# )
It's not the billions of dollars (though, that has helped keep Java from becoming irrelevant). It's that Java and C# are not dynamic. They were made for high performance (well, Java wasn't from the beginning, but it has been for a long time, now). Javascript was made for high productivity: less code for a given amount of work done on some data set.
In a couple Adobe presentations I've seen (I'm not a Flash dev), their performance improvement claims were in line with other dynamic languages that later got compilation attempts, like Lua and Smalltalk. Dynamic languages are
different than static languages. In a static language, you must either annotate all types, or all types must be inferable by the compiler.
Code:
function gogo( arg1, arg2, arg3) {code} <- typical dynamic
int function gogo( int arg1, short arg2, string arg3) {code} <- typical static
All functions must execute as if type checks were put off until the very last moment, in a dynamic system. Many object-oriented dynamic systems allow this to go as far as allowing existing compiled code to operate on data types that have not yet been created in the system (including one of the first few OOPLs ever created, Smalltalk). In the static language, it must be proven before it can compile.
The big performance advantage is that fixed-size variables can be known memory offsets, and variable-sized variables can be pointers at some known offset. In the dynamic case, the system must always check the type, and be prepared to find relevant operations for it, and execute them. There will be ranges of dynamic code that can be so proven, and get sped up a lot by a native compiler, since those checks can be removed, and parts of the operations can be inlined...but, in practical code, they tend to be fairly small ranges at a time--somewhere, it gets to a point where it can't prove that correctness automatically, anymore.
In Java, types are strict, and based on common machine types. The compiler knows what type every operation can take (this can be worked around, technically, since everything is a subtype of Object, but that's ugly, bad form, prone to problems, etc.).
^ That won't compile.
Javascript has loose typing, so the above will work fine. It should yield, "25," which can then be used as the string, "25," or the number, 25. Now, considering a web browser, and that the web is 99.x plain text, that actually makes a lot of sense. Not using the above as a substitute for math, but being able to mix numbers and strings without a bunch of typecast and parse calls littering much of the code (if you want it as a number, FI, explicitly parse it once at the very beginning, and then leave it that way).
To get the performance JIT JS engines can (browsers are doing it, too), part of what they do is infer static types from what operations are done. However, needing many functions to be able to handle different input types, there are limits on how efficient that can get (IE, there will be some function call that will get stuck with all the dynamic checking), overall, even if most of the types in your code can be 100% figured out.
Then, JS uses prototyping for objects, and they are dynamic, where Java's are static. Java, with static typing, can define an object's layout in memory, on a given machine, and then build the rest of the code around that.
Address { int streetnum, string street, string city, byte state, int zip } can be well-defined in memory. Every one is the same. So it can do things like define streetnum as the object's address + 8, FI. These kinds of things can reduce the access of fixed-size variables to a handful of assembly instructions, and not too much more for variable-sized objects that need pointing to, like strings.
In Javascript, that Address is going to be a dictionary, and require a key lookup every single access, into a trie or hash table. It's not really a defined type of record before the runtime system gets it, but is made as it goes along. You can subtype just by adding a key/value pair to the table (so, what takes a whole new text file in Java, and typically tens of lines of code in C#, might be done with just a few lines of Javascript). Compared to an offset of some bytes, or going to another pointer or two, that's going to be pretty expensive. It will then also have to chase pointers for things like strings, just like a static language would.
Macromedia more or less chose Javascript because it was a fad, at the time. But, if Adobe could start from scratch, and did not choose an ECMAScript*, they still would get a language with most of Javascript's features. An ideal language would look a lot like Javascript, but with strict typing, rather than loose. It's hard to show in small easy snippets, but the difference in code written for sizable projects can be reduced by 10-100x, by not having to fuss with all the typing directly in the code. But, having to keep up with typing dynamically in the system eats performance potential. TANSTAAFL.
* Hmmm. TANSTAAFL, inferable, and inlined were not in the spellchecker dictionary, but ECMAScript was.
Facebook
Twitter