RFR (L) JDK-8209301: JVM rename is_anonymous, host_klass to unsafe specific terminology ahead of Unsafe.defineAnonymousClass deprecation

[Lois Foltan]

On 8/16/2018 7:13 PM, David Holmes wrote:

> Hi Lois,
>
> On 17/08/2018 6:17 AM, Lois Foltan wrote:
>> Ahead of the work to support a new MethodHandle.Lookup functionality 
>> to define an anonymous or other class within the context of a hosted 
>> class, (see JDK-8171335), please review this clean up to use the 
>> terminology of "is_unsafe_anonymous" instead of "is_anonymous" for 
>> classes defined to the VM via Unsafe.defineAnonymousClass. 
>> InstanceKlass' "host_klass" method has also been renamed to 
>> "unsafe_anonymous_host" in order to avoid confusion with 
>> "nest_host".  It is not anticipated that JDK-8171335 work will use 
>> the same "anonymous" terminology.
>
> This generally seems okay.
Thanks David for reviewing!

>
> Reading through this we seem to have some loose wording in places. For 
> example in classloaderData.cpp we have:
>
>  // Returns true if this class loader data is a class loader data
>  // that is not ever freed by a GC.  It must be one of the builtin
> -// class loaders and not anonymous.
> +// class loaders and not unsafe anonymous.
>
> which I think should read something like:
>
> "It must be [the CLD] for one of the builtin class loaders and not the 
> CLD for an unsafe anonymous class."
I like your rewording, will update the comment.

>
> More generally we seem to refer to just "anonymous" or "anonymous 
> class loader" when I think we mean the CLD for an anonymous class. At 
> least I don't think we have "anonymous class loaders" do we?
No we do not.  I debated for awhile as what exactly to do with 
specifically ClassLoaderData's _is_unsafe_anonymous field indicating 
that the CLD is currently dedicated to containing one VM unsafe 
anonymous class whose lifecycle is controlled by its class' java mirror, 
not its class loader.  I wanted to rename it to "_has_class_lifecycle", 
but decided to postpone this decision until the work to support 
JDK-8171335 is flushed out.  I anticipate that the concept of a 
singleton ClassLoaderData will be shared by Unsafe.defineAnonymousClass 
and the new Lookup.defineClass functionality.

Thanks,
Lois

>
> Anyway that's somewhat distinct from the renaming exercise.
>
> Thanks,
> David
>
>> open webrev at 
>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8209301/webrev/
>> bug link at https://bugs.openjdk.java.net/browse/JDK-8209301
>>
>> Testing: hs-tier1-4, jdk-tier1-3 (complete)
>>                 hs-tier4-5 (in progress)
>>
>> Thanks,
>> Lois