4 ms·
The JIT and threading / memory model were bolted on afterwards. The JIT isn't even part of the JVM spec. (Unless this has changed.)
by rwjwjuwjudf 11y ago
The JIT and threading / memory model were bolted on afterwards. The JIT isn't even part of the JVM spec. (Unless this has changed.)
- haberman 11y agoThe Sun JVM has had a JIT since 1998: https://en.wikipedia.org/wiki/Java_version_history#J2SE_1.2 https://en.wikipedia.org/wiki/Java_version_history#J2SE_1.2
- rwjwjuwjudf 11y agoYou were asking about design, not implementation. The way Java works is there's a language spec and a VM spec and then organizations are free to implement them as they see fit. So JVM design is referring to what's in the spec. What's wrong with Sun's implementation? Well, they did the best they could, given that there's no design / spec to work from (for the JIT). The memory model was completely replaced in the spec in ~2005 (to work better on multi-core CPUs and stuff), and the threading model was changed in the spec sometime in the 90s (from green threads to native threads).
- rbehrends 11y agoWhich was after JDK 1.0. The JVM was originally implemented as a bytecode interpreter; Sun licensed the Symantec JIT compiler later for 1.1, then eventually added HotSpot several years after 1.0, derived from Smalltalk technology. The original design of the JVM was for embedded systems, not for running server applications with heaps in the 10s of GB of memory. The threading model, which allows for near arbitrary sharing of memory, is still a significant source of complexity for both the JIT and the GC and has changed multiple times since the JVM's inception. Modern JVM implementations have little to do with the original design, but still have to deal with design decisions made 20 years ago for completely different architectures and with only limited foresight.