Why JDK-8157181 conditional in JDK 9 EA ?

Evgeny Mandrikov mandrikov at gmail.com
Mon Dec 19 00:39:13 UTC 2016


David, thank you for the explanations.

Regards,
Evgeny

On Sun, Dec 11, 2016 at 11:28 PM David Holmes <david.holmes at oracle.com>
wrote:

> Hi Evgeny,
>
> On 12/12/2016 7:58 AM, Evgeny Mandrikov wrote:
> > Hi,
> >
> > Rory O'Donnell gave me an advice [1] to provide our concerns about
> > JDK-8157181 [2] here. But excuse me if this is wrong place or too late.
> >
> > In JaCoCo project [3] we accidentally discovered JDK-8157181 [2], which
> > revealed that we were generating bytecode that violates JVMLS [4]. 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 [2], especially in
> > presence of tickets for backporting [5]. 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.
>
> Regards
> David
>
> > Best regards,
> > Evgeny Mandrikov
> >
> > [1] https://groups.google.com/d/msg/jacoco-dev/sRXi8TD96js/w4T8DpffAwAJ
> > [2] https://bugs.openjdk.java.net/browse/JDK-8157181
> > [3] http://www.jacoco.org/jacoco/index.html
> > [4] https://github.com/jacoco/jacoco/pull/434
> > [5] https://bugs.openjdk.java.net/browse/JDK-8161987
> >
>


More information about the hotspot-dev mailing list