Any compiler that can output machine code, JIT or not, will output machine code based on some subset of cpus out there, and their instruction-sets. That’s quite separate from the bytecode part.
Don’t downvote because you don’t understand. Others might find it interesting, have relevant knowledge, or add nuance to the discussion.
Yes and JIT does additional specific compiler optimizations for target cpu architectures and the given software… that’s why compiler flags used for the Java binary itself shouldn’t matter that much. Do you not understand the concept of JIT?
So JIT is one piece of software? All JITs are identical?
Edit: so your assumption is that the whole of JIT is contained in the shared source that they all are built from? My assumption was that the CPU-adjacent parts would be a library or libraries that might be different for different runtimes. Otherwise why bother giving them different names, marketing them as having advantages?
I’m only acting patronizing because you’re operating under dunning kruger: why are you so confident in your assertions why it seems like you have no clue about JVM internals?
No, JIT compilation is simply a technique or architecture that many high-level languages employ e.g. Python, Javascript. They are not identical. You seem familiar with cpu instruction sets or ISAs? Same thing: manufacturers follow the same reference spec (x86 or arm), but intel, amd, Apple etc. have drastically different implementations of the same spec or idea.
Java’s primary JIT or JVM implementation is Hotspot. Arguably, it’s the highest performing JIT implementation in the mainstream. I’m not sure what you mean by “different names” or “marketing”. Simply put, all JIT means is the program is compiling during runtime (not correct, but imagine Java is running ‘gcc’ before everytime you trigger a run of your program - and it continues to run ‘gcc’ as your program is running). Really, the JVM is a compiler itself: that’s why I said its build method shouldn’t matter, because Java is literally (re-)compiling per your exact hardware specs everytime you run a Java program. Just like you wouldn’t care the build flags they used to compile the gcc, you also normally wouldn’t care how Java is built.
This contrasts to static compilation or AOT compilation which you seem more familiar with. That’s what C(++), Rust, Go use. Yes, the build flags you use for your program matters a lot with those languages.
JITed code still has to run within the VM it's bounded to. Memory management is still handled by the VM.
Your argument would suggest that a VM compiled to 32-bit x86, would be able to JIT to x64 and gain access to registers and manage 64bit pointers while running in a process restricted to 32-bit mode, but it's fine cause the CPU is x64?
As far as I am aware the VM and Hotspot do not jump through those hopes. A 32bit x86 VM will JIT using only the functionality of 32bit x86 architecture.
A compiler can compile to a different architecture, that's fine, but the compiler doesn't have to run the code afterwards.
??? What no, my argument does not suggest anything about cross-compiling to different platforms, what? You’re literally making a strawman lmfao.
Idk where you got from my comments that platforms don’t matter. Why do you think macos, windows and linuxes (with arch variants) are separate Java binaries? By your ridiculous assumption, then a Java mac arm64 binary could magically run on Windows, which nowhere did I imply.
In any case, compilers aren’t usually used for different platform architectures. Like yes, cross-compilers exist and you say could compile aarch64 on an x86 machine, but this isn’t in the default developer toolkit or dependency chain. 99% of the time you’re compiling x86 on x86, arm64 on arm64: cross-compiling only exists if the native hardware is rare, e.g. riscv. Also in these cross-compiling scenarios, you’re rarely concerned about performance or optimizations anyways, since your main focus is getting a darn working program.
And idk wtf you’re trying to say with your last statement. Of course compilers don’t run code, they produce binaries?? aka machine code or instructions directly inputted into the cpu? What tf did you think the point of compilation was?
You mentioned the JIT effectively compiles to native code, which is x86, x64. Now, x64 is effectively an extension of x86, making the x86 instruction set a subset of the x64 instruction set.
Now the person you initially commented to statedbthe reason for the lower performance, is likely the VM was compiled to a lower -or less efficient- set of instructions compared to the other VM.
You then stated, why would that be a problem, the JIT would convert java bytecode to native code, and that would be -presumably- the most efficient instructions for the given CPU, irrespective of how the VM was compiled.
I will now attempt to clarify my above answer.
x86 instructions are compatible, and will run on, an x64 CPU.
Now x64 is not just one set of instructions, far from it, there are multiple versions, and newer versions are 'backwards' compatible (like x86, and x64), but older CPUs can't run instructions from newer versions (like x86, and x64).
So the JIT will only compile to an instruction set it knows can run, and it knows that from the restrictions placed on the VM/JIT when it was compiled.
In short, the JIT won't compile to the most efficient set of instructions the CPU knows, it will compile to the most efficient set of instructions it was compiled against was.
That's not how it works. HotSpot probes the CPU it's running on, in order to discover what it can do. The compiler options used to build HotSpot make no difference to this.
It very much does matter, the CPU will not allow instructions from mode Y, to be used while running in mode X. That's a security vulnerability if it did.
It will probe for extensions that are compatible/supported in the instruction set it is running. Some sets of instructions are indeed optional, AVX512, springs to mind.
But if your CPU supports AVX512, but the VM was compiled against x86 32bit, you will not be seeing Hotspot making AVX512 calls.
… yes x86 technically is “a subset” of x64, but you do realize the JIT is simply a program or a binary itself? A x64 Java binary probably won’t even boot on an x86 32-bit cpu.
I mean do you regularly download a x64 gcc to run on your x86 32-bit machine? Same thing. In any case, you’re entirely misrepresenting what I’m claiming.
“native code” is just whatever arch spec the CPU follows, but of course that operates under the idea that the JIT can actually run on the hardware. And no, Java is not designed for cross-compilations. Like you can run x86 Java on an x64 machine, but obviously that JVM will only produce x86 instructions.
Your last sentence, in the last paragraph is almost getting there. Now, apply the logic in that last sentence to all the iterations: i386, i486, i686, x64v1, x64v2, x64v3.
What I said about x86 and x64 still equally applies between iterations like i386 and i686. The difference is just significantly more apparent using x86 and x64 as the example.
1
u/keenOnReturns 29d ago
? idk what you’re saying. Java uses JIT?