RFR: 8255342: Remove non-specified JVM checks on Classes with Record attributes [v2]

John R Rose jrose at openjdk.java.net
Tue Oct 27 16:47:24 UTC 2020


On Tue, 27 Oct 2020 12:21:22 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Looks good, Harold!
>
> Thanks David and Coleen for the reviews!

This was a good example of a VM anti-pattern that's easy to fall into, which I call "The Gratuitous Restriction".  There's a wide range of correctness checks the VM *could* do, but deciding which ones it *should* do is surprisingly subtle.  When designing a new feature, there's a certain impulse to reject every suspicious input, and even to fish around in the design asking "what can we reject, that doesn't appear to have a meaning?"  This impulse is (often) rooted in a legitimate desire to reduce implementation work by constraining inputs (rejecting a class file before trying to interpret something that smells funny).  But there are four downsides:

1. The rejected thing might turn out to have a meaning after all, but now we are blocked from discovering what it might be.  (This is my favorite.  When once we said "value types can't extend abstract classes", I thought, "yeah, that's what we're saying now; just wait a while.")

2. The rejection we threw into the code to save ourselves work has to be rigorously specified in the JVMS and kept there forever.  (We may get tired of looking at it, and it may obscure more important material in the JVMS.)

3. The rejection we threw into the code to save ourselves work has to be maintained forever, and if we ever disturb it our own VM will be non-compliant with the JVMS.  (We may get tired of maintaining it.)

4. Maybe, if you get into the habit of making them, they can build up as performance debt.  Enough extra checks will start to slow down the JVM.

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

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


More information about the hotspot-runtime-dev mailing list