Why JDK-8157181 conditional in JDK 9 EA ?
david.holmes at oracle.com
Sun Dec 11 22:28:08 UTC 2016
On 12/12/2016 7:58 AM, Evgeny Mandrikov wrote:
> Rory O'Donnell gave me an advice  to provide our concerns about
> JDK-8157181  here. But excuse me if this is wrong place or too late.
> In JaCoCo project  we accidentally discovered JDK-8157181 , which
> revealed that we were generating bytecode that violates JVMLS . What was
> a bit surprising - is a conditional behavior of verifier based on bytecode
> version. At a time of discovery we had no ability to compile into bytecode
> version 9 given the state of tools in build stack (minifiers, verifiers,
> etc) and had only ability to execute with JDK 9 EA. I guess that many
> projects might relatively easily start testing 9 EA just as runtime
> environment, while change of a target still might require bigger investment
> as was the case for us. From there, I wonder why this logic was was not
> made unconditional as was discussed in JDK-8157181 , especially in
> presence of tickets for backporting . Or maybe this happened, but we
> just didn't noticed since bug on our side was fixed? The verification
> itself is great and IMO might reveal bugs in tools that generate bytecode.
My comment in the bug report sums up the situation:
"If this is a long standing non-compliance with the JVMS then its impact
can not be considered high. The longer the VM and spec do not match the
more likely we adjust the spec to match the VM behaviour. When that is
not feasible then the usual approach is to enforce the correct rules as
of the current classfile version, otherwise we risk introducing
compatibility issues. Even if we make the correct behaviour the default,
we will usually provide a flag to enable the old behaviour for
compatibility purposes. Only if this is a security concern would we
force the change to the new behaviour. "
After much (mostly internal) discussion the compatibility argument won
out. The backports exist to put in the change that causes the JIT to
detect the "illegal" assignments and disable aggressive optimization of
the final field.
> Best regards,
> Evgeny Mandrikov
>  https://groups.google.com/d/msg/jacoco-dev/sRXi8TD96js/w4T8DpffAwAJ
>  https://bugs.openjdk.java.net/browse/JDK-8157181
>  http://www.jacoco.org/jacoco/index.html
>  https://github.com/jacoco/jacoco/pull/434
>  https://bugs.openjdk.java.net/browse/JDK-8161987
More information about the hotspot-dev