On 19/04/2017 5:51 PM, John Rose wrote:
On Apr 19, 2017, at 12:14 AM, David Holmes <david.hol...@oracle.com
<mailto: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.
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
