On Thu, 5 May 2022 18:54:49 GMT, Alan Bateman <al...@openjdk.org> wrote:

> We mailed porters-dev in Sep 2021 to give a heads up that this feature would 
> require porting work so it shouldn't be a surprise. We have been open to 
> including other ports with the initial integration but it was never a goal to 
> have all the ports done in advance of that.

It is understandable to ship the preview feature not implemented on all 
platforms. It is even understandable to ship the final product feature that 
breaks some platforms in an clearly understandable way, prompting platform 
maintainers to implement the agreed-upon, final Java feature. What I am seeing, 
though, is that just running `java -version` (!) after integrating a *preview 
feature* is broken!

> Most of the new code in the VM is only used when running with 
> --enable-preview. You'll see several places that test 
> Continuations::enabled(). It should be possible to get these port running 
> without -enable-preview without much effort. The feature has to be 
> implemented to pass all the tests of course.

It is not as clear-cut, unfortunately. I see there are substantial changes in 
deopt machinery with post-call NOPs -- and there maybe more stuff lurking after 
that one is implemented -- so it is not as simple as changing `Unimplemented()` 
to guarding with `Continuations::enabled()`. So this looks to me that the core 
deopt machinery is affected, whether Loom is enabled or not. Is the impact of 
that deopt machinery change on the VM stability and VM ports discussed, 
understood, documented somewhere?

I would have honestly expected those core changes to be heavily conditionalized 
with either `ifdef`-s, or runtime checks, or both, so that both unimplemented 
platforms had the old behavior *and* the implemented platforms had a fallback 
to old behavior if preview feature was broken. The current code is fine for 
experimental Loom repo, but I firmly believe mainline should have much stronger 
safety/reliability requirements.

My fear is that an integration like this would wreck JDK 19 release. So my 
question stands: Are we breaking those platforms? Are we sure the unconditional 
VM changes are problem-free, implementable everywhere, etc? The answer might be 
"Yes, we are integrating, let the chips fall where they may", but I also 
believe that should be the call made by responsible platform/VM architects, who 
should explicitly weigh in and accept the risk of wide JDK 19 breakage.


PR: https://git.openjdk.java.net/jdk/pull/8166

Reply via email to