Timeline for How can an interpreter run code without translating into machine code?
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 19, 2024 at 1:00 | comment | added | user1937198 | In the extreme case, for a degenerate purely linear program with no loops, repreated calls, or recursion, Hotspot will behave as an interpreter. | |
| May 19, 2024 at 0:59 | comment | added | user1937198 | The reason for this is that compiling bytecode usually takes longer than interpreting at least a couple of times, so early pure JIT JVMs had horrible startup times compared to interpreters, due to the amount of time spent compiling code that would only be run once at startup, before the application could start its task. They also had issues with pauses for compiling rarely used code, that might only be hit once in an applications runtime. Asynchronous compiling of repeatedly executed code allows the application to start working immediately, whilst minimizing the overhead of the compiler. | |
| May 19, 2024 at 0:52 | comment | added | user1937198 | The statement that their is no interpreter in Hotspot (the standard java runtime in the JDK) is not strictly true. Hotspot is not primarily an interpreter, but it does include an interpreter as the first stage of its execution pipeline. The just in time compiler is run as a background task, compiling code that has been interpreted multiple times. | |
| May 14, 2024 at 14:01 | comment | added | 8bittree | The distinction between bytecode and machine code is smaller than one might think. Java bytecode has been run directly on hardware and x86 or ARM machine code are often run in software. | |
| May 13, 2024 at 14:39 | history | answered | FluidCode | CC BY-SA 4.0 |