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

Kim Barrett kim.barrett at oracle.com
Wed Apr 3 02:33:09 UTC 2019

> On Apr 2, 2019, at 9:37 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> On 4/2/19 4:51 PM, Kim Barrett wrote:
>>> 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.
> Should we really put it to the beginning? It takes < 1ms.
> May be other tasks are more expensive and should be run first as now.
> But I don't know what is strategy is used here: run short or long tasks first.
> If you think it is okay to move it - I will move it.

The JVMCI cleaning task is (at least currently) a serial task. All of
the others are parallelized, in the sense that each thread will take
pieces of the first of those tasks until there aren't any left, and
then move on to the next task. Putting the serial task at the end
allows all the parallel work to be completed as one thread picks up
that remaining serial piece, and then chugs along on its own while all
the other threads are now idle. Putting the serial task first means
all the other threads can be working through the parallelized work.
The serial thread joins the others on the remaining parallel work when
it's done, and if there isn't any then it's a good thing we started
the serial work first, as it's the long pole.

>> 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)
> Yes, I will do this. I tried use JVMCI_ONLY with regular ',' and it failed.

The COMMA macro is exactly for this sort of thing where one needs a deferred comma.
It’s a relatively recent addition, and not used all that much yet.

More information about the graal-dev mailing list