Draft JVMS changes for Nestmates
john.r.rose at oracle.com
Wed Apr 19 07:51:06 UTC 2017
On Apr 19, 2017, at 12:14 AM, David Holmes <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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the valhalla-spec-experts