RFR: 8276905: Function frag_col has a deployment target which is incompatible with this OS [v2]

[Erik Joelsson]

On Fri, 12 Nov 2021 17:45:09 GMT, Phil Race <prr at openjdk.org> wrote:

> My understanding is that the flag here affects ONLY the metal compiler - for compiling metal shaders. And if you don't specify -Dsun.java2d.metal=true (since metal is off by defau�lt) its a 100% no-op for the rest of the JDK. And already, if you specify Dsun.java2d.metal=true and you are on 10.13 or lower, we do not honour the request so we haven't changed what platforms will work at all if we do it this way. So our effective deployment target for metal is already 10.14

This explanation certainly makes a good case for giving this particular tool invocation special treatment. If we don't want to bump the general deployment target version, then this makes sense.

> And I also would not be surprised if someone wants to backport this to 17u, in which case a config change would have the effect of making 17u no longer run on macos 12 .. which I guess will happen sometime during the life of the LTS but right now ??

I would be fine with backporting a general deployment target version change to 10.14 to 17u LTS. Apple are very aggressive with dropping support for older OS versions. We don't really have any obligations to maintain compatibility with legacy versions of macos. We just haven't actively dropped compatibility (which is different from what any particular distributor officially supports) unless there has been some technical limitation before. But, as you have now explained, we already have a runtime guard for this optional feature, so we aren't actually forced to change the global deployment target.

> So making it a metal-specific change is what I think we should do FOR NOW and we can have a follow-on fix that aligns both of these .. maybe that is a subsequent JDK 18 fix, or perhaps it should be an early JDK 19 fix ?

I'm ok with a metal specific change here, targeting 10.14, but it needs a comment referencing the global value and explaining that there is a runtime guard around this. Also note that on aarch64 the global value is 11.00.00, and in that case we should use the global value.

-------------

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