[13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library

[Kim Barrett]

> On Apr 2, 2019, at 4:41 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> I ran Kitchensink with G1 and -Xmx8g. I observed that Remark pause times are not consistent even without Graal.
> To see effect I added time spent in JVMCI::do_unloading() to GC log (see below [3]). The result is < 1ms - it is less than 1% of a pause time.
> 
> It will have even less effect since I moved JVMCI::do_unloading() from serial path to parallel worker thread as Stefan suggested.

A few comments, while I'm still looking at this.

------------------------------------------------------------------------------
src/hotspot/share/gc/shared/parallelCleaning.cpp
 213     JVMCI_ONLY(_jvmci_cleaning_task.work(_unloading_occurred);)

I think putting the serial JVMCI cleaning task at the end of the
ParallelCleaningTask can result in it being mostly run by itself,
without any parallelism. I think it should be put up front, so the
first thread in starts working on it right away, while later threads
can pick up other work.

That's assuming this is all needed. I see that the Java side of things
is using WeakReference to do cleanup. I haven't figured out yet why
this new kind of weak reference mechanism in the VM is required in
addition to the Java WeakReference cleanup.  Still working on that...

------------------------------------------------------------------------------
src/hotspot/share/gc/shared/parallelCleaning.cpp
 194 #if INCLUDE_JVMCI
 195   _jvmci_cleaning_task(is_alive),
 196 #endif

This could be made a bit less cluttered:

  JVMCI_ONLY(_jvmci_cleaning_task(is_alive) COMMA)

------------------------------------------------------------------------------
src/hotspot/share/runtime/jniHandles.cpp
 192 #if INCLUDE_JVMCI
 193   JVMCI::oops_do(f);
 194 #endif

I don't think that belongs here.

------------------------------------------------------------------------------