Is intermediate representation (such as bytecodes or .net IL) still an advantage?

Question

Is intermediate representation--IR--such as Java bytecodes or .net CIL, still an advantage? Can’t we just deploy software components in source-code?

One of the arguments in favor of IR, was the portability of the software components, which avoids the need of compiling the source code for each target architecture (regarding the existence of a virtual machine for that architecture). IR offers an abstraction over each architecture specificities. In the same way and together with metadata it brings other advantages in terms of enabling security guarantees; checking safety accesses; etc.

Today, some technologies such as Node.js (with V8 engine) introduces the idea of deployable components in source code, called packages in Node.js (I am not sure if it was a seminal idea in Node.js). Source code contains the same information of IR + metadata. Moreover, using components in source code, does not prevent the runtime engine from using the same principles of a modern virtual machine such as just-in-time compilation and late-bound data types, which allows adaptive optimization and thus in theory can yield faster execution.

So, is there any advantage of deploying software components in IR over components in source-code?

Answer 1

Based in some opinions, I think there is NO advantage and it is just a matter of design choice. And, that’s the answer that I would give to my own question, which I will substantiate next.

In fact, maybe the main reason for the absence of a deployable IR format in JavaScript is (as pointed in HansPassant's comment):

Javascript was just done backwards.

I really like this statement. However, I am not sure about the second part when @HansPassant states:

WebAssembly is likely to be JS' bytecode.

Documentation about WebAssembly modules states:

While WebAssembly modules are designed to interoperate with ES6 modules in a Web environment, WebAssembly modules are defined independently of JavaScript and do not require the host environment to include a JavaScript VM.

And that reinforces my idea that the choice for a deployable IR format is just a design option. In truth there is not any clear Disadvantage in maintaining components in source-code. So, for instance, I am not sure if existing Node.js ecosystem will ever adopt WebAssembly modules.

Finally in jackmott's answer, he presents a clear analysis about possible advantages of IR, but at the end he consider:

the distinction can get blurry.

I totally agree and here I enumerate why all IR advantages are rebuttable by the source-code approach:

1. logic obfuscation – the same can be done at source-code level.

2. reduced size – not always. In some cases a component in source-code can be even smaller than its compiled version.

3. faster JIT compilation – just on the first method call. Subsequent invocations will benefit from the same optimizations, regardless the method body was in IR or source-code.

4. Compiling over Transpiling – just two different approaches to the same end--supporting other high-level programming languages. Today there is at least one Javascript transpiler for most common used programming languages.

5. low-level hand tune – Is that an advantage? I believe automated tools can do a better job than hand tune. Moreover, in some cases hand-tune could break patterns and avoid optimizations.

Answer 2

The distinctions begin to blur in some cases which I will note below. But in general:

• One advantage of an IR bytecode is that is obfuscates the logic you have created. However, so does minified javascript, and to a similar degree in some cases.

• Another advantage is reduced size, but minified javascript is also small, perhaps similarly so.

• A third advantage would be faster JIT compilation, as the bytecode is closer to actual machine instructions that source code would be. While you can do JIT with source code, it will take more instructions and/or memory to do it. So all else equal, you should get better performance with bytecode deployment. It should be noted that rarely is all else equal, so you may not always observe this performance advantage, or it may be relatively small depending on your performance needs.

• A fourth advantage would be that you can more easily have other languages target a bytecode IR than target a language. While it is possible to create a language that compiles to javascript, it is usually easier to compile down to a bytecode, and you will have more control over the performance and correctness of the result, since you are compiling down to something closer to machine code.

• Lastly, it is possible, and even done in some cases, by this very website for instance, to hand tune your bytecode for performance, just as people do sometimes with assembler.

Now the distinction can get blurry. One could imagine a fairly heavy-weight bytecode format, perhaps due to the need to support a vast range of hardware, or perhaps due to poor design, which might be farther removed from machine code than say, interpreted ANSI C would be. But if we assume that a bytecode is a reasonable attempt to approximate machine instructions, and assume that "Source code" represents something as high level as C or higher, then the advantages above should hold.