Is there any real advantage from Bytecode JIT execution over native code beside portability? (General and OS-Design)

1
votes

Is there any real advantage from Bytecode JIT execution over native code beside possible implementation of platform independency?

Apparently languages that use "virtual machines" over Bytecode JIT execution are attributed several advantages. But in what extend would this really affect a discussion concerning advantages/disadvantages of native code and JIT execution?

Here's a list of attributes that I identify, the question is in what extend does this also apply to native code - if the compiler supports it...

Security

VM runtime environments can observe the running application for e.g. buffer overflows.

  • So first question is if this is done by the "runtime environment", means e.g. by the class library or during JIT execution?

  • Memory bounds-checking exist also for native code compilers. Any other/general restrictions here?

Optimization

Classical optimization should be possible in native code compilers, too. See LLVM which in fact uses the generated bitcode to run optimization on, before compiling to native code.

  • Maybe there would be something like a dynamic optimization in JIT by e.g. identifying things to optimize related to the execution context. Could maybe be possible for a native compiler, too, to generate some code to optimize the execution during runtime. But dont't know if something like this is implemented.

  • Popular VM implementations do this - the question is if this really excuses a real advantages over native code.

Threading

I don't cound this while threading also in a VM is dependent on the native Thread implementation of the OS.

If we identify that there is no real advantage over native code and that there is always a runtime drawback in JIT... than this leads to the next question:

Does an operating system design based on JIT execution (e.g. Singularity, Cosmos, ...) make sense?

I could maybe identify one advantages: An OS with this design needs no MMU. Means there is no process seperation that makes use of the MMU, but a seperation between objects/components in software. But is it worth it?

Best regards ;-)

1
operating-systembytecodejitvm-implementation
As for dynamic optimization by a native compiler: If the AOT compiler "generates some code to optimize the execution during runtime", you already have a JIT. And that JIT will sure as hell use a more high-level description of the program, because that's far easier to optimize. Have you tried inlining virtual calls given nothing but machine code (e.g. no information about classes)? – user395760
Good objection.. So dynamic optimization and also GC are should be added to my list above. Think to answer it in detail it would need detailed measuring on current implementations... – user914455

1 Answers

1
votes

Theoretically, they could take advantage of the platform/CPU they run on, to compile faster code.

In practice, I personally haven't come across any case in which that actually happens.

But there's also other issues. Higher-level languages that compile into bytecode also happen to have garbage collection, which is very useful in some domains. It's not because of the JIT compiler per se, but having a JITter makes it a lot easier practically because often the language is easier for a JITter to analyze and figure out e.g. where pointers go on the stack, etc.