Hotspot Express (HSX)

[Hohensee, Paul]

HSX was mentioned in the “Backporting features” thread a few times. As one of those who initiated HSX back in 6u4 (it was actually Dave Cox’s idea), I thought I’d chime in. HSX was adopted not only because it made the latest performance and features available in update releases, but also because of the (large) negative impact on JDK 6 of resource diversion to JDK 5 backports. The 6-month release train amounts to JSX (JDK Express), so it’s not like the concept is new or untested. And, all the other “unexpected” positive results of instituting JSX were presaged by HSX. It’s hard to argue for JSX and against HSX at the same time. :)

HSX was just Hotspot back in the day, but looks to include the CI and Graal now (I’ll just call the whole thing “Hotspot”), so it’s a bigger project than before. I’ve been playing around with supporting HSX in the latest LTS release. Right now, that’s dropping Hotspot from JSX into the latest JDK 11 update release (14 into 11.0.6). When JDK 17 ships, that would become the HSX target, replacing JDK 11. I’m looking at replacing JDK 11’s make/hotspot, src/hotspot, test/hotspot, and src/jdk.internal.* with the corresponding JSX release directories. I’m including backports to JDK 11 common code (mostly makefiles and the odd library) to make it possible to build both vanilla JDK 11 and HSX in the same repo. If HSX were policy, supporting two kinds of builds wouldn’t be necessary. :)

A big attraction of HSX is that higher performance and features can be made available in the latest LTS release. JSX was supposed to make a separate HSX unnecessary, but there hasn’t been much JSX adoption. Azul’s MTS proposal might help, but it involves even more backporting effort to support two more release trains. The big problem is that users are skeptical based on their experience with the large amount of change in LTS releases. They haven’t really thought about how the much smaller amount of change in JSX releases means that they’re much less risky to adopt than LTS releases. When HSX was rolled out in 6u4, there was the same skepticism, but it quickly went away. Think of HSX as a kind of half-way house. If HSX were available and users accepted it again, imo they’d be much more inclined to try JSX. If JSX were widely accepted, in the long run both HSX and LTS releases could be dispensed with.

There’s a tradeoff between the engineering resources necessary to do backports and those necessary to keep Hotspot viable in the previous LTS release. The cost of doing backports is rather high, with engineers from Oracle, Red Hat, SAP, Amazon, Azul, and others participating. From Aleksey’s pushes- scripts, there were 519 Hotspot (just to src/hotspot) pushes to 11.0.3 through 11.0.6, and 120 for 11.0.7 so far. These are not small numbers and are about half the totals, which are 1038 for 11.0.3 through 11.0.6, and 275 for 11.0.7. And, Oracle and the rest of the community do the same work twice. For HSX, that would not be the case.

For HSX, Hotspot must be able to find out in which JDK it’s executing and adjust accordingly. There’s a school of thought that doing so constrains what you can do with Hotspot and the JDK, but I didn’t see that when HSX was policy. Unfortunately (from my pov), most of the small amount of code needed has been removed from Hotspot, some fairly recently. The interface between Hotspot and the JDK libraries would have to be (re)defined and come under CSR control, and Hotspot build/test would have to be (re)made truly independent of the rest of the JDK. Imo, doing these would be a good idea whether or not HSX exists. My experience so far has been that the Hotspot/JDK library interface changes quite slowly and is thus easy to track, but that build/test changes rapidly and is heavily interdependent between Hotspot and the rest of the JDK.

Another issue is QA. While it’s true that full test cycles must be done on the latest LTS whether or not HSX is used, imo the inherent quality of the latest Hotspot is greater than that of a patched Hotspot. That’s because backport patches may not work well outside the context in which they were made and thus lead to instability. The more patches, the worse the problem becomes. When HSX was policy, there were essentially no extra QA issues with running Hotspot in earlier releases.

Thanks,
Paul