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

[David Holmes]

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.

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."

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?

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