Language Mix-up
The project I’ve been working on for the past week has the following language stack/mix-up:
- C#
- C++/CLI
- C++
- Python
Which means that when we run our C# tests, we have the C runtime, CLR and Python interpreter in one process.
Maybe its time for a chip manufacturer to consider Pacifica from the perspective of CLR/SEAM - JNode and Singularity would both benefit from the performance improvements, as would every other VM application.
What happened to the Java chip?
Java chips do exist, but they don’t give the performance you would think. For example see the Jazelle extensions for ARM.
Its tempting to think of converting bytecodes to opcodes, but remember all sorts of useful things are missing from the simplified Java bytecode system - like interupts - and its difficult to implement some of the bytecode ops in hardware. Most Java chips only do 60% of the opcodes in hardware.
One of the points of bytecode/p-code systems is they are an intermediate representation which makes them hardware independent. They’re a programmer abstraction - “managed code” where memory, threads, etc are all handled for you. To really do a lot of these services you’d need hardware implementations of these services, or java bytecode equivalents. There are people working on these ideas…
Things like Pacifica and the underlying technology will help - but ultimately there needs to be direct hardware support for garbage collection, threads, jit, object memeory, object stacks, etc. at the CPU level. Its these services and not the bytecodes where the performance and memory issues lie.
[...] VBA was countered with a lot more Python integration into the framework. With a little pairing a colleague and I got the engine running with python code as well. [...]