JIT Compiler Support Might Be Added To GCC 4.9

[JS987]

Thanks for the great explanation.
That sounds like a huge win for packagers.
At a minimum they'd be able to get rid of the x32/x64 split and halve their repo size. Of course they'd still have to carry enough binaries to boot-strap the machine.

Complete applications with libraries shouldn't be JIT compiled because they will suffer from same problems like Java ones - slow start-up, high memory usage.

[liam]

Complete applications with libraries shouldn't be JIT compiled because they will suffer from same problems like Java ones - slow start-up, high memory usage.

Presumably they would only need to be jitted once then stored as binaries.

[JS987]

Presumably they would only need to be jitted once then stored as binaries.

It should be possible to compile bytecode to native executable or library during installation of application or library, but that library doesn't seem to target such case.

[liam]

It should be possible to compile bytecode to native executable or library during installation of application or library, but that library doesn't seem to target such case.

I'm sure I'm missing something but that seems trivial. Perhaps it's something they intend to add shortly?

[Luke_Wolf]

Complete applications with libraries shouldn't be JIT compiled because they will suffer from same problems like Java ones - slow start-up, high memory usage.

Slower to start up the first time sure (assuming they're caching the binary), but High Memory consumption isn't going to happen. Excessive memory consumption is a language design issue related to things like how much metadata you're carrying around, whether the code is garbage collected or not, otherwise it's just pointer sizes and how much stuff is being optimized out... So no the memory consumption should be about the same as it is now not higher.

[JS987]

Slower to start up the first time sure (assuming they're caching the binary), but High Memory consumption isn't going to happen. Excessive memory consumption is a language design issue related to things like how much metadata you're carrying around, whether the code is garbage collected or not, otherwise it's just pointer sizes and how much stuff is being optimized out... So no the memory consumption should be about the same as it is now not higher.

Caching isn't possible because all native code (libraries, executables) have to be stored in files (example: files in /usr/bin, /usr/lib) which are:
- owned by root - read-only for user in order system would be secure - native code can't be easily modified
- world readable, which enables memory sharing with mmap by every process of every user which is necessary to minimize size of private memory of every process

[log0]

Caching isn't possible because all native code (libraries, executables) have to be stored in files (example: files in /usr/bin, /usr/lib) which are:
- owned by root - read-only for user in order system would be secure - native code can't be easily modified
- world readable, which enables memory sharing with mmap by every process of every user which is necessary to minimize size of private memory of every process

The caching(compilation) could happen during installation. So you would have something like gentoo, but with bytecode (with bytecode I mean the IR). I am not sure whether one would save that much compared to direct source code distribution though. It is just the parsing step that would fall away.

It would allow to mix bytecode independent of the source language(assuming the language is supported by gcc) I assume, which might be interesting.

[nbtrap]

Presumably they would only need to be jitted once then stored as binaries.

Wouldn't that undermine one of the advantages of JIT compilation? I always thought that the great thing about JIT compilers was that they can make optimizations that static compilers can't because they (JIT) have more information come runtime. But since the extra information is variable, a once-only compilation would have to skip such optimizations.