One follow up to a new comment John made ...
On 20/04/2017 10:09 AM, John Rose wrote:
On Apr 19, 2017, at 12:56 AM, David Holmes <david.hol...@oracle.com
<mailto:david.hol...@oracle.com>> wrote:
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.
I see what the problem is: The only checking I am proposing
is syntax checking on the names. If by "deep checking" you
mean loading classes from the names, I agree, we don't want
to do that. The MemberOfNest attribute is passive. It does
not need to initiate loads; it just needs to validate claims
of nest membership by other classes.
(I even doubt Dan's assertion that in some corner cases,
when the nest-host is trying out a private access, there
must be some loading done to validate the access. Probably
we can get away with no loading at all, just name checks
against already-loaded classes.)
If the access is legitimate then no loading is needed as the common
nest-host is already loaded. Currently the implementation will load the
purported nest-host if needed, so in the case where they are not
actually nest-mates this would load the "foreign" nest-host class. But
when the initiator is the nest-host the check can be inverted by
searching NestMembers for the target class instead. I see one quirky
aspect of this in that in the unlikely case that the target class is in
NestMembers but does not itself list the nest-host in its MemberOfNest,
the access check will succeed, but before the invocation can actually
happen the target class must be linked and at that point validation
would fail (assuming we adopt the fail-fast model).
David
— John
