News for hackers. Stuff that matters.

A comment on Malloc envy. Parent comment

Re:Malloc envy by rbehrends on Monday April 04, 2016 @06:06PM (#11426124)
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

[ Parent | on HN ]
Re:Malloc envy by haberman on Monday April 04, 2016 @06:09PM (#11426146)
In what sense was the JVM not designed to be a JIT compiler in a multi-threaded environment?
[ Parent | on HN ]
Re:Malloc envy by jerf on Monday April 04, 2016 @06:36PM (#11426298)
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.
[ Parent | on HN ]
Re:Malloc envy by haberman on Tuesday April 05, 2016 @01:26PM (#11432394)
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/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.

[ Parent | on HN ]
Re:Malloc envy by sangnoir on Monday April 04, 2016 @06:49PM (#11426371)
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)

[ Parent | on HN ]
Re:Malloc envy by Manishearth on Tuesday April 05, 2016 @02:54AM (#11428383)
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.
[ Parent | on HN ]
Re:Malloc envy by sangnoir on Saturday April 09, 2016 @01:52PM (#11462371)
But that has nothing to do with the question he is responding to; regarding Java's suitability as a multithreaded JIT
[ Parent | on HN ]
Re:Malloc envy by jerf on Tuesday April 05, 2016 @09:06AM (#11430015)
Tu quoque.
[ Parent | on HN ]
Re:Malloc envy by rwjwjuwjudf on Monday April 04, 2016 @06:12PM (#11426171)
The JIT and threading / memory model were bolted on afterwards. The JIT isn't even part of the JVM spec. (Unless this has changed.)
[ Parent | on HN ]
Re:Malloc envy by haberman on Monday April 04, 2016 @06:56PM (#11426411)
The Sun JVM has had a JIT since 1998: https://en.wikipedia.org/wiki/Java_version_history#J2SE_1.2
[ Parent | on HN ]
Re:Malloc envy by rbehrends on Monday April 04, 2016 @07:55PM (#11426743)
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.

[ Parent | on HN ]
Re:Malloc envy by rwjwjuwjudf on Monday April 04, 2016 @07:16PM (#11426536)
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).

[ Parent | on HN ]
Re:Malloc envy by the8472 on Monday April 04, 2016 @06:41PM (#11426328)
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.

[ Parent | on HN ]