5 ms·

The JVM has a lot of other reasons to pause [1]. A big problem with using the JVM as an example is that it's an enormously complex architecture that wasn't real

The JVM has a lot of other reasons to pause [1]. A big problem with using the JVM as an example is that it's an enormously complex architecture that wasn't really designed for the kind of workloads it is subjected to these days. For example, the complexities involved in having a JIT compiler in a multi-threaded environment that wasn't designed from the ground up for that purpose can be pretty scary (e.g. the method deoptimization issue in the video). The effort that has gone into the various JVM implementations both impresses and scares me. [1] https://www.youtube.com/watch?v=Y39kllzX1P8 https://www.youtube.com/watch?v=Y39kllzX1P8

haberman 11y ago
In what sense was the JVM not designed to be a JIT compiler in a multi-threaded environment?
- 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 ago
    The 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 ago
      You 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 ago
      Which 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.
- jerf 11y ago
  Like (somewhat ironically) Javascript, Java's origins can be very easy to forget, and also like Javascript, both are surprisingly humble. Javascript was banged together in a week, and Java was intended to be a language for developing constrained set-top box UIs in the 1990s. While that does not render them intrinsically unsuitable after decades of development for the sort of tasks that they are put to today, the early days of a language still inevitably color it forever when backwards compatibility is a big concern.
  - sangnoir 11y ago
    To distill your contribution to its essence: Parent: what's wrong with the JVM as a multithreaded-JIT? You: Java is similar to Javascript. Javascript was terribly designed in the 90's. Therefore Java sucks . QED. You should try your hand at politics! Don't answer the question (Java), instead, segue into the more comfortable topic/what you want to talk about (Javascript)
    - Manishearth 11y ago
      Um, jerf gave a reason why Java's history affects it here and noted how it's similar to Javascript in that regard on the side; not the other way around. The JS comparison was not part of their argument.
      - sangnoir 11y ago
        But that has nothing to do with the question he is responding to; regarding Java's suitability as a multithreaded JIT
    - jerf 11y ago
      Tu quoque.
  - haberman 11y ago
    I don't buy this at all. The original Java whitepaper from 1995 mentions both multithreading and JIT compilation: http://www.cs.dartmouth.edu/~mckeeman/cs118/references/OriginalJavaWhitepaper.pdf http://www.cs.dartmouth.edu/~mckeeman/cs118/references/Origi... It even says that the byte-code format was specifically designed with JIT compilation in mind: > The byte code can be translated on the fly (at runtime) into machine code for the particular CPU the application is running on. For those used to the normal design of a compiler and dynamic loader, this is somewhat like putting the final machine code generator in the dynamic loader. > The byte code format was designed with this in mind, so the actual process of generating machine code is generally simple. Reasonably good code is produced: it does automatic register allocation and the compiler does some optimization when it produces the bytecode. The idea that JIT compilation was retroactively bolted onto the Java ecosystem is absurd. Perhaps more than any other technology, Java brought JIT compilation into the mainstream, starting more than 20 years ago.
the8472 11y ago
Most other safepoints pauses are much shorter and far less common than GC pauses on multi-GB heaps. For some applications those still are a problem, yes, but others would be happy if those were the only ones they'd experience.

haberman 11y ago

In what sense was the JVM not designed to be a JIT compiler in a multi-threaded environment?

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 ago
  The 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 ago
    You 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 ago
    Which 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.
jerf 11y ago
Like (somewhat ironically) Javascript, Java's origins can be very easy to forget, and also like Javascript, both are surprisingly humble. Javascript was banged together in a week, and Java was intended to be a language for developing constrained set-top box UIs in the 1990s. While that does not render them intrinsically unsuitable after decades of development for the sort of tasks that they are put to today, the early days of a language still inevitably color it forever when backwards compatibility is a big concern.
- sangnoir 11y ago
  To distill your contribution to its essence: Parent: what's wrong with the JVM as a multithreaded-JIT? You: Java is similar to Javascript. Javascript was terribly designed in the 90's. Therefore Java sucks . QED. You should try your hand at politics! Don't answer the question (Java), instead, segue into the more comfortable topic/what you want to talk about (Javascript)
  - Manishearth 11y ago
    Um, jerf gave a reason why Java's history affects it here and noted how it's similar to Javascript in that regard on the side; not the other way around. The JS comparison was not part of their argument.
    - sangnoir 11y ago
      But that has nothing to do with the question he is responding to; regarding Java's suitability as a multithreaded JIT
  - jerf 11y ago
    Tu quoque.
- haberman 11y ago
  I don't buy this at all. The original Java whitepaper from 1995 mentions both multithreading and JIT compilation: http://www.cs.dartmouth.edu/~mckeeman/cs118/references/OriginalJavaWhitepaper.pdf http://www.cs.dartmouth.edu/~mckeeman/cs118/references/Origi... It even says that the byte-code format was specifically designed with JIT compilation in mind: > The byte code can be translated on the fly (at runtime) into machine code for the particular CPU the application is running on. For those used to the normal design of a compiler and dynamic loader, this is somewhat like putting the final machine code generator in the dynamic loader. > The byte code format was designed with this in mind, so the actual process of generating machine code is generally simple. Reasonably good code is produced: it does automatic register allocation and the compiler does some optimization when it produces the bytecode. The idea that JIT compilation was retroactively bolted onto the Java ecosystem is absurd. Perhaps more than any other technology, Java brought JIT compilation into the mainstream, starting more than 20 years ago.

the8472 11y ago

Most other safepoints pauses are much shorter and far less common than GC pauses on multi-GB heaps. For some applications those still are a problem, yes, but others would be happy if those were the only ones they'd experience.