Draft JVMS changes for Nestmates

[David Holmes]

Correction below ...

On 19/04/2017 5:56 PM, David Holmes wrote:
> 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.

Sorry John - brain fart on my part. We're talking about the symbols that 
have just been parsed and loaded into the constant pool, not the classes 
those symbols name.

David
-----

> 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