On Apr 19, 2017, at 12:14 AM, David Holmes <david.hol...@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. 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
