[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Re: RFR: 8255342: Remove non-specified JVM checks on Classes with Record attributes [v2]
From:       Remi Forax <forax () univ-mlv ! fr>
Date:       2020-10-27 17:11:22
Message-ID: 1286200946.905530.1603818682163.JavaMail.zimbra () u-pem ! fr
[Download RAW message or body]

----- Mail original -----
> De: "John R Rose" <jrose@openjdk.java.net>
> À: "hotspot-runtime-dev" <hotspot-runtime-dev@openjdk.java.net>
> Envoyé: Mardi 27 Octobre 2020 17:47:24
> Objet: Re: RFR: 8255342: Remove non-specified JVM checks on Classes with Record attributes [v2]

> On Tue, 27 Oct 2020 12:21:22 GMT, Harold Seigel <hseigel@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.")

by example, in the future an enum may have record components but not inherits from java.lang.Record 
  enum Color(int red, int green, blue) { RED(255, 0, 0), ... }

> 
> 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.


Rémi
[prev in list] [next in list] [prev in thread] [next in thread]