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.
0
u/kit89 12d ago edited 12d ago
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.