RFR(preliminary): JDK-8185034: Cleanup and consolidate Metaspace coding

[Thomas Stüfe]

Hi all,

I am working on https://bugs.openjdk.java.net/browse/JDK-8185034, an
umbrella change for a number of cleanups in the metaspace area.

I have two parts done and would like to gauge opinions (especially
objections) if this is going in the right direction.

1) Renaming MetaspaceAux to MetaspaceUtils (very boring rename)

http://cr.openjdk.java.net/~stuefe/webrevs/8185034-metaspace-cleanups/8185034-metaspace-cleanup-1-rename-metaspaceaux/webrev.00/webrev/

2) Splitting class Metaspace into two classes - basically splitting off the
static utility functions. The new class "ClassLoaderMetaspace" holds only
the classloader specific metaspace memory and is the "metaspace" in the
sense of metaspace held by one class loader. The class "Metaspace" now is
just a namespace (AllStatic - poll: should I use a real namespace? And if
yes, how should I treat the private methods?) holding the central static
Metaspace methods like "static Metaspace::allocate()". As opposed to
MetaspaceUtils, formerly MetaspaceAux, which just is a sink for metaspace
auxiliary stuff.

http://cr.openjdk.java.net/~stuefe/webrevs/8185034-metaspace-cleanups/8185034-metaspace-cleanup-2-split-Metaspace-class/webrev.00/webrev/

I think I already found a small error resulting from the dual use of the
class Metaspace for global static utility functions as well as classloader
specific functions. See https://bugs.openjdk.java.net/browse/JDK-8199007.
So, this split is a good thing if it prevents such errors.

Please note: these preliminary patches apply atop of my current work on
metaspace chunk coalescation, so you will need the following patch first:
http://cr.openjdk.java.net/~stuefe/webrevs/metaspace-coalescation/2018-03-01/webrev-full/webrev/source.patch


Thank you,

Thomas