4 ms·

Is it actually a JIT? It's just compiling everything unconditionally. I guess the fact that the second tier replaces previously compiled functions with more opt

Is it actually a JIT? It's just compiling everything unconditionally. I guess the fact that the second tier replaces previously compiled functions with more optimized versions makes it a JIT? Or does the definition of JIT require recompiling in response to information about which code would benefit most?

chrisseaton 9y ago
Do you think for something to be a JIT it must only compile code immediately before it's used? In that case the only real JIT I know of is basic-block-versioning. I think almost all JITs will compile branches or methods to some extent before they are actually needed. Yours is probably not a reasonable definition therefore. I think a JIT is just a compiler that can compile as the program is running.
- rcthompson 9y ago
  > Do you think for something to be a JIT it must only compile code immediately before it's used? I mean, that's more or less what the name "just-in-time compiler" implies. I'm aware that the name is not necessarily a precise definition, but I'm not sure how far the definition stretches. Does JIT have a precise agreed-upon definition, or is it somewhat more vaguely defined?
  - chrisseaton 9y ago
    No these terms never have precise meanings, and trying to debate them too much doesn't achieve much. But if your definition doesn't actually work for any examples of the thing you're defining at all except one then it's probably wrong.
    - rcthompson 9y ago
      Ok, fair enough. I was worried that there was some precise definition I had missed, but if that's not the case, I agree there's no point in debating it.
      - emn13 9y ago
        Well, there's at least one definition that's pretty noncontroversial, if not terribly satisfying or precise: it's not a JIT if you compile well in advance of any indication the program needs to be run. Whether that lazy-compilation strategy is fine-grained or not isn't clearcut, I believe. I think if you distribute a C program with a bash bootstrapper calling plain old gcc to compile and run the C code only when needed, even gcc might be considered a (coarse-grained, rather rudimentary) JIT in that context.
        kybernetikos 9y ago
        Like TCCBoot? https://bellard.org/tcc/tccboot.html https://bellard.org/tcc/tccboot.html
MaxBarraclough 9y ago
> Is it actually a JIT? It's just compiling everything unconditionally. Still counts as JIT in my book, but you're right that it's a bit subtle. Unix-style configure/build/install isn't considered JIT. Installing a .Net application is pretty similar, but we don't consider it JIT. In the usual .Net model, what's distributed is IR rather than source-code. Compilation to native code happens at install time. The build-and-install process is less explicit than the Unix way, and it's less error-prone (fewer dependency issues and issues with the compiler not liking your source code). Really it's a very similar model to the Unix one, but we call one JIT and not the other. Oracle Java, of course, only ever compiles to native code at runtime, and never caches native code. 'Proper' JIT. (This may be set to change in the near future though.) Interestingly, .Net seems to be moving in the direction of full static compilation, or they wouldn't be asking devs to rebuild UWP apps to incorporate framework fixes - https://aka.ms/sqfj4h/ https://aka.ms/sqfj4h/
- caf 9y ago
  It might be fun to make a source-based distribution where every binary in /usr/bin started off as a link to a script that built and installed the requested executable (over the top of the link), before executing it.
  - _jal 9y ago
    Wouldn't be difficult to modify FreeBSD to do that. /usr/ports is just a little more than one indirection away.
  - uep 9y ago
    Or how about a fuser filesystem on Linux to do the same? That sounds like an interesting idea. Just don't make the mistake of accidentally typing some obscenely large binary like firefox, chrome, or clang... I think it would need to be integrated into the package management system pretty tightly (or have one of its own) to get all of the shared library dependencies.
  - MaxBarraclough 9y ago
    Source-based distros essentially do that, they just cache the binaries. Various research OSs are JIT-based, of course. It looks like JX (a Java operating system) caches its native code, so it's not 'pure JIT' https://github.com/mczero80/jx/blob/5fbeae79/libs/compiler_env/jx/compiler/persistent/CodeFile.java#L343 https://github.com/mczero80/jx/blob/5fbeae79/libs/compiler_e... It looks like Cosmos (a C# operating system) does the same https://en.wikipedia.org/wiki/IL2CPU https://en.wikipedia.org/wiki/IL2CPU
didibus 9y ago
To me it's a JIT if the compiler is needed to run the code. If it means compile on start, it still requires the compiler to be used at load time. Non JIT would mean you can distribute the code without the compiler. If you can't do that, its JITTED or interpreted, if instead of requiring a compiler to be present you require an interpreter.
- MaxBarraclough 9y ago
  I like this definition.

chrisseaton 9y ago

Do you think for something to be a JIT it must only compile code immediately before it's used? In that case the only real JIT I know of is basic-block-versioning. I think almost all JITs will compile branches or methods to some extent before they are actually needed. Yours is probably not a reasonable definition therefore. I think a JIT is just a compiler that can compile as the program is running.

rcthompson 9y ago
> Do you think for something to be a JIT it must only compile code immediately before it's used? I mean, that's more or less what the name "just-in-time compiler" implies. I'm aware that the name is not necessarily a precise definition, but I'm not sure how far the definition stretches. Does JIT have a precise agreed-upon definition, or is it somewhat more vaguely defined?
- chrisseaton 9y ago
  No these terms never have precise meanings, and trying to debate them too much doesn't achieve much. But if your definition doesn't actually work for any examples of the thing you're defining at all except one then it's probably wrong.
  - rcthompson 9y ago
    Ok, fair enough. I was worried that there was some precise definition I had missed, but if that's not the case, I agree there's no point in debating it.
    - emn13 9y ago
      Well, there's at least one definition that's pretty noncontroversial, if not terribly satisfying or precise: it's not a JIT if you compile well in advance of any indication the program needs to be run. Whether that lazy-compilation strategy is fine-grained or not isn't clearcut, I believe. I think if you distribute a C program with a bash bootstrapper calling plain old gcc to compile and run the C code only when needed, even gcc might be considered a (coarse-grained, rather rudimentary) JIT in that context.
      - kybernetikos 9y ago
        Like TCCBoot? https://bellard.org/tcc/tccboot.html https://bellard.org/tcc/tccboot.html

MaxBarraclough 9y ago

> Is it actually a JIT? It's just compiling everything unconditionally. Still counts as JIT in my book, but you're right that it's a bit subtle. Unix-style configure/build/install isn't considered JIT. Installing a .Net application is pretty similar, but we don't consider it JIT. In the usual .Net model, what's distributed is IR rather than source-code. Compilation to native code happens at install time. The build-and-install process is less explicit than the Unix way, and it's less error-prone (fewer dependency issues and issues with the compiler not liking your source code). Really it's a very similar model to the Unix one, but we call one JIT and not the other. Oracle Java, of course, only ever compiles to native code at runtime, and never caches native code. 'Proper' JIT. (This may be set to change in the near future though.) Interestingly, .Net seems to be moving in the direction of full static compilation, or they wouldn't be asking devs to rebuild UWP apps to incorporate framework fixes - https://aka.ms/sqfj4h/ https://aka.ms/sqfj4h/

caf 9y ago
It might be fun to make a source-based distribution where every binary in /usr/bin started off as a link to a script that built and installed the requested executable (over the top of the link), before executing it.
- _jal 9y ago
  Wouldn't be difficult to modify FreeBSD to do that. /usr/ports is just a little more than one indirection away.
- uep 9y ago
  Or how about a fuser filesystem on Linux to do the same? That sounds like an interesting idea. Just don't make the mistake of accidentally typing some obscenely large binary like firefox, chrome, or clang... I think it would need to be integrated into the package management system pretty tightly (or have one of its own) to get all of the shared library dependencies.
- MaxBarraclough 9y ago
  Source-based distros essentially do that, they just cache the binaries. Various research OSs are JIT-based, of course. It looks like JX (a Java operating system) caches its native code, so it's not 'pure JIT' https://github.com/mczero80/jx/blob/5fbeae79/libs/compiler_env/jx/compiler/persistent/CodeFile.java#L343 https://github.com/mczero80/jx/blob/5fbeae79/libs/compiler_e... It looks like Cosmos (a C# operating system) does the same https://en.wikipedia.org/wiki/IL2CPU https://en.wikipedia.org/wiki/IL2CPU

didibus 9y ago

To me it's a JIT if the compiler is needed to run the code. If it means compile on start, it still requires the compiler to be used at load time. Non JIT would mean you can distribute the code without the compiler. If you can't do that, its JITTED or interpreted, if instead of requiring a compiler to be present you require an interpreter.

MaxBarraclough 9y ago
I like this definition.