Draft JVMS changes for Nestmates

[David Holmes]

On 19/04/2017 5:51 PM, John Rose wrote:
> On Apr 19, 2017, at 12:14 AM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>>
>> Some of these are a lot more awkward to do during classfile parsing
>> and will require symbol comparisons. I was wanting to avoid "deep
>> validation" of NMs as it penalizes all the good code. Having a "bad"
>> NM entry seems harmless as these entries are only used to validate the
>> initial claim of nest membership. If an entry is "bad" then by
>> definition it will not match with any claimee.
>
> I don't see how that is a significant concern.  The symbol bodies are
> hot in cache
> at the point we would check prefixes, since they are already being
> scanned for other
> purposes, such as initial interning, and also syntax checking.  Existing
> processing
> is exactly as deep (or shallow) as the checks I want.

I don't follow that. If I'm loading a nest-top class and validating its 
NM entries none of those entries need have been loaded yet and so none 
will be in the cache.

David
-----

> If we turn off the "verify" flag for class loading, then maybe we can
> buy something
> by dropping those (and all the other) constraint checks.
>
> By syntax checking, I mean that if I mention a CONSTANT_Class in the CP,
> and its corresponding CONSTANT_Utf8 has a broken syntax (e.g., "." instead
> of "/", or two "//" in a row) the JVMS mandates an error.  But those are the
> same bytes I want to look at when they are referenced by a MoN or NMs
> attribute.  It will all be in cache, and the cycles to do the checks will be
> undetectable.
>
> — John