Draft JVMS changes for Nestmates
david.holmes at oracle.com
Thu Apr 20 01:11:40 UTC 2017
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
>> 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.
>> 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., "."
>> 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
>> — John
More information about the valhalla-spec-experts