RFR: 8227054: ServiceThread needs to know about all OopStorage objects

[Mandy Chung]

Hi Kim,

A passing comment (not a review):

40 // For serviceability agent.

ServiceThread is used for serviceability such as JVM TI and M&M but not 
serviceability agent.

Mandy

On 7/25/19 3:59 PM, Kim Barrett wrote:
> 8227054: ServiceThread needs to know about all OopStorage objects
> 8227053: ServiceThread cleanup of OopStorage is missing some
>
> Please review this change in how OopStorage objects are managed and
> accessed.  There is a new (all static) class, OopStorages, which
> provides infrastructure for creating all the storage objects, access
> via an enum-based id, and iterating over them.
>
> Various components that previously managed their own storage objects
> now obtain them from OopStorages.  A number of access functions have
> been eliminated as part of that, though some have been retained for
> internal convenience of a component.
>
> The set of OopStorage objects is now declared in one place, using
> x-macros, with collective definitions and usages ultimately driven off
> those macros.  This includes the ServiceThread (which no longer needs
> explicit knowledge of the set, and is no longer missing any) and the
> OopStorage portion of WeakProcessorPhases.  For now, the various GCs
> still have explicit knowledge of the set; that will be addressed in
> followup changes specific to each collector.  (This delay minimizes
> the impact on Leo's in-progress review that changes ParallelGC to use
> WorkGangs.)
>
> This change also includes a couple of utility macros for working with
> x-macros.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8227054
> https://bugs.openjdk.java.net/browse/JDK-8227053
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8227054/open.00/
>
> Testing:
> mach5 tier1-3
>