[13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library
Vladimir Kozlov
vladimir.kozlov at oracle.com
Tue Apr 30 21:37:22 UTC 2019
Thank you, Coleen, for reviews of these huge changes.
Best regards,
Vladimir K
On 4/30/19 2:28 PM, coleen.phillimore at oracle.com wrote:
>
> This looks good to me. Thank you for addressing my comments.
> Coleen
>
> On 4/26/19 6:46 PM, Vladimir Kozlov wrote:
>> Hi
>>
>> I have 2 new deltas for easy review.
>>
>> Delta 1 is mostly JVMCI HotSpot refactoring and cleanup:
>> http://cr.openjdk.java.net/~kvn/8220623/webrev_delta1.07/
>>
>> - Cleanup #include jvmci files.
>> - Removed BoolObjectClosure parameter from JVMCI::do_unloading() since it is not used. In JDK 13 this parameter is
>> removed from other places too.
>> - Added mtJVMCI type to track memory used by JVMCI.
>> - Passed Handles as constant references.
>> - Moved JNIAccessMark, JVMCIObject, MetadataHandleBlock class to separate new files.
>> - Moved JVMCI methods bodies from jvmciRuntime.cpp into new jvmci.cpp file.
>> - Moved bodies of some JVMCIEnv methods from .hpp into jvmciEnv.cpp file. They use JNIAccessMark and
>> ThreadToNativeFromVM and I can't use them in header file because they require #include inline.hpp files.
>> - Moved bodies of some HotSpotJVMCI methods into jvmciJavaClasses.cpp file because, again, they need
>> jniHandles.inline.hpp.
>> - Moved JVMCICompileState class definition to the beginning of jvmciEnv.hpp file.
>>
>> Delta 2:
>> http://cr.openjdk.java.net/~kvn/8220623/webrev_delta2.07/
>>
>> - Changed MetadataHandleBlock fields which are used only by one instance to static.
>> - Renamed field _jmetadata::_handle to _value and corresponding access methods because it was confusing:
>> handle->handle().
>> - Switched from JNIHandleBlock to OopStorage use for _object_handles.
>> - Additional JVMCI Java side fix for libgraal.
>>
>> Full:
>> http://cr.openjdk.java.net/~kvn/8220623/webrev.07/
>>
>> I think I addressed all comments I received so far.
>>
>> Thanks,
>> Vladimir
>>
>> On 4/9/19 7:25 PM, Vladimir Kozlov wrote:
>>> Thank you, Coleen
>>>
>>> On 4/9/19 1:36 PM, coleen.phillimore at oracle.com wrote:
>>>>
>>>> I think I missed graal-dev with this reply. I have a few other comments.
>>>>
>>>> +void MetadataHandleBlock::do_unloading(BoolObjectClosure* is_alive) {
>>>>
>>>>
>>>> We've removed the is_alive parameter from all do_unloading, and it appears unused here also.
>>>
>>> Yes, I can remove it.
>>>
>>>>
>>>> I don't know about this MetadataHandles block. It seems that it could be a concurrent hashtable with a
>>>> WeakHandle<> if it's for jdk11 and beyond. Kim might have mentioned this (I haven't read all the replies
>>>> thoroughly) but JNIHandleBlock wasn't MT safe, and the new OopStorage is safe and scalable.
>>>
>>> Yes, Kim also suggested OopStorage. I did not get into that part yet but I will definitely do.
>>>
>>>>
>>>> + jmetadata allocate_handle(methodHandle handle) { return allocate_metadata_handle(handle()); }
>>>> + jmetadata allocate_handle(constantPoolHandle handle) { return allocate_metadata_handle(handle()); }
>>>>
>>>> +CompLevel JVMCI::adjust_comp_level(methodHandle method, bool is_osr, CompLevel level, JavaThread* thread) {
>>>>
>>>> +JVMCIObject JVMCIEnv::new_StackTraceElement(methodHandle method, int bci, JVMCI_TRAPS) {
>>>>
>>>> +JVMCIObject JVMCIEnv::new_HotSpotNmethod(methodHandle method, const char* name, jboolean isDefault, jlong
>>>> compileId, JVMCI_TRAPS) {
>>>>
>>>> Passing metadata Handles by copy will call the copy constructor and destructor for these parameters unnecessarily.
>>>> They should be passed as *const* references to avoid this.
>>>
>>> Okay.
>>>
>>>>
>>>> +class MetadataHandleBlock : public CHeapObj<mtInternal> {
>>>>
>>>>
>>>> There should be a better mt? for this. mtCompiler seems appropriate here. Depending on how many others of these,
>>>> you could add an mtJVMCI.
>>>
>>> mtJVMCI is good suggestion.
>>>
>>>>
>>>> + if (TraceNMethodInstalls) {
>>>>
>>>>
>>>> We've had Unified Logging in the sources for a long time now. New code should use UL rather than adding a
>>>> TraceSomething option. I understand it's supposed to be shared with JDK8 code but it seems that you're forward
>>>> porting what looks like old code into the repository.
>>>
>>> Yes, we should use UL for this.
>>>
>>> Existing JIT code (ciEnv.cpp) still not using UL for this:
>>> http://hg.openjdk.java.net/jdk/jdk/file/f847a42ddc01/src/hotspot/share/ci/ciEnv.cpp#l1075
>>>
>>> May be I should update it too ...
>>>
>>>>
>>>> Coleen
>>>>
>>>>
>>>> On 4/9/19 4:00 PM, coleen.phillimore at oracle.com wrote:
>>>>>
>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.06/src/hotspot/share/classfile/classFileParser.cpp.udiff.html
>>>>>
>>>>> It appears this change is to implement https://bugs.openjdk.java.net/browse/JDK-8193513 which we closed as WNF. If
>>>>> you want this change, remove it from this giant patch and reopen and submit a separate patch for this bug.
>>>
>>> Thank you for pointing it. I will do as you suggested.
>>>
>>>>>
>>>>> It shouldn't be conditional on JVMCI and should use the normal unified logging mechanism.
>>>
>>> Okay.
>>>
>>>>>
>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.06/src/hotspot/share/runtime/thread.hpp.udiff.html
>>>>>
>>>>> *!_jlong__pending_failed_speculation;*
>>>>>
>>>>>
>>>>> We've been trying to remove and avoid java types in hotspot code and use the appropriate C++ types instead. Can
>>>>> this be changed to int64_t? 'long' is generally wrong though.
>>>
>>> This field should be java type since it is accessed from Java Graal:
>>>
>>> http://hg.openjdk.java.net/jdk/jdk/file/f847a42ddc01/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java#l401
>>>
>>>
>>>>>
>>>>> I seem to remember there was code to deal with metadata in oops for redefinition, but I can't find it in this big
>>>>> patch. I was going to look at that.
>>>
>>> May be it is MetadataHandleBlock::metadata_do() (in jvmciRuntime.cpp)?
>>>
>>>>>
>>>>> Otherwise, I've reviewed the runtime code.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>>>>
>>>>> Coleen
>>>>>
>>>>> On 4/4/19 3:22 AM, Vladimir Kozlov wrote:
>>>>>> New delta:
>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.06/
>>>>>>
>>>>>> Full:
>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.06/
>>>>>>
>>>>>> New changes are based on Kim and Stefan suggestions:
>>>>>>
>>>>>> - Moved JVMCI::oops_do() from JNIHandles to places where it should be called.
>>>>>> - Moved JVMCI cleanup task to the beginning of ParallelCleaningTask::work().
>>>>>> - Used JVMCI_ONLY macro with COMMA.
>>>>>> - Disable JVMCI build on SPARC. We don't use it - neither Graal or AOT are built on SPARC. Disabling also helps to
>>>>>> find missing JVMCI guards.
>>>>>>
>>>>>> I ran hs-tier1-3 testing - it passed (hs-tier3 includes graal testing).
>>>>>> I started hs-tier4..8-graal testing.
>>>>>> I will do performance testing next.
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>>> On 4/3/19 9:54 AM, Vladimir Kozlov wrote:
>>>>>>> On 4/2/19 11:35 PM, Stefan Karlsson wrote:
>>>>>>>> On 2019-04-02 22:41, Vladimir Kozlov 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.
>>>>>>>>
>>>>>>>> Kitchensink isn't really a benchmark, but a stress test. I sent you a private mail how to run these changes
>>>>>>>> through our internal performance test setup.
>>>>>>>
>>>>>>> Okay, I will run performance tests there too.
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> It will have even less effect since I moved JVMCI::do_unloading() from serial path to parallel worker thread as
>>>>>>>>> Stefan suggested.
>>>>>>>>>
>>>>>>>>> Stefan, are you satisfied with these changes now?
>>>>>>>>
>>>>>>>> Yes, the clean-ups look good. Thanks for cleaning this up.
>>>>>>>>
>>>>>>>> Kim had some extra comments about a few more places where JVMCI_ONLY could be used.
>>>>>>>>
>>>>>>>> I also agree with him that JVMCI::oops_do should not be placed in JNIHandles::oops_do. I think you should put it
>>>>>>>> where you put the AOTLoader::oops_do calls.
>>>>>>>
>>>>>>> Okay.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> StefanK
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Here is latest delta update which includes previous [1] delta and
>>>>>>>>> - use CompilerThreadStackSize * 2 for libgraal instead of exact value,
>>>>>>>>> - removed HandleMark added for debugging (reverted changes in jvmtiImpl.cpp),
>>>>>>>>> - added recent jvmci-8 changes to fix registration of native methods in libgraal (jvmciCompilerToVM.cpp)
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.05/
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Vladimir
>>>>>>>>>
>>>>>>>>> [1] http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.04/
>>>>>>>>> [2] Original webrev http://cr.openjdk.java.net/~kvn/8220623/webrev.03/
>>>>>>>>> [3] Pauses times from Kitchensink (0.0ms means there were no unloaded classes, 'NNN alive' shows how many
>>>>>>>>> metadata references were processed):
>>>>>>>>>
>>>>>>>>> [1.083s][1554229160638ms][info ][gc,start ] GC(2) Pause Remark
>>>>>>>>> [1.085s][1554229160639ms][info ][gc ] GC(2) JVMCI::do_unloading(): 0 alive 0.000ms
>>>>>>>>> [1.099s][1554229160654ms][info ][gc ] GC(2) Pause Remark 28M->28M(108M) 16.123ms
>>>>>>>>>
>>>>>>>>> [3.097s][1554229162651ms][info ][gc,start ] GC(12) Pause Remark
>>>>>>>>> [3.114s][1554229162668ms][info ][gc ] GC(12) JVMCI::do_unloading(): 3471 alive 0.164ms
>>>>>>>>> [3.148s][1554229162702ms][info ][gc ] GC(12) Pause Remark 215M->213M(720M) 51.103ms
>>>>>>>>>
>>>>>>>>> [455.111s][1554229614666ms][info ][gc,phases,start] GC(1095) Phase 1: Mark live objects
>>>>>>>>> [455.455s][1554229615010ms][info ][gc ] GC(1095) JVMCI::do_unloading(): 4048 alive 0.821ms
>>>>>>>>> [455.456s][1554229615010ms][info ][gc,phases ] GC(1095) Phase 1: Mark live objects 344.107ms
>>>>>>>>>
>>>>>>>>> [848.932s][1554230008486ms][info ][gc,phases,start] GC(1860) Phase 1: Mark live objects
>>>>>>>>> [849.248s][1554230008803ms][info ][gc ] GC(1860) JVMCI::do_unloading(): 3266 alive 0.470ms
>>>>>>>>> [849.249s][1554230008803ms][info ][gc,phases ] GC(1860) Phase 1: Mark live objects 316.527ms
>>>>>>>>>
>>>>>>>>> [1163.778s][1554230323332ms][info ][gc,start ] GC(2627) Pause Remark
>>>>>>>>> [1163.932s][1554230323486ms][info ][gc ] GC(2627) JVMCI::do_unloading(): 3474 alive 0.642ms
>>>>>>>>> [1163.941s][1554230323496ms][info ][gc ] GC(2627) Pause Remark 2502M->2486M(4248M) 163.296ms
>>>>>>>>>
>>>>>>>>> [1242.587s][1554230402141ms][info ][gc,phases,start] GC(2734) Phase 1: Mark live objects
>>>>>>>>> [1242.899s][1554230402453ms][info ][gc ] GC(2734) JVMCI::do_unloading(): 3449 alive 0.570ms
>>>>>>>>> [1242.899s][1554230402453ms][info ][gc,phases ] GC(2734) Phase 1: Mark live objects 311.719ms
>>>>>>>>>
>>>>>>>>> [1364.164s][1554230523718ms][info ][gc,phases,start] GC(3023) Phase 1: Mark live objects
>>>>>>>>> [1364.613s][1554230524167ms][info ][gc ] GC(3023) JVMCI::do_unloading(): 3449 alive 0.000ms
>>>>>>>>> [1364.613s][1554230524167ms][info ][gc,phases ] GC(3023) Phase 1: Mark live objects 448.495ms
>>>>>>>>>
>>>>>>>>> [1425.222s][1554230584776ms][info ][gc,phases,start] GC(3151) Phase 1: Mark live objects
>>>>>>>>> [1425.587s][1554230585142ms][info ][gc ] GC(3151) JVMCI::do_unloading(): 3491 alive 0.882ms
>>>>>>>>> [1425.587s][1554230585142ms][info ][gc,phases ] GC(3151) Phase 1: Mark live objects 365.403ms
>>>>>>>>>
>>>>>>>>> [1456.401s][1554230615955ms][info ][gc,phases,start] GC(3223) Phase 1: Mark live objects
>>>>>>>>> [1456.769s][1554230616324ms][info ][gc ] GC(3223) JVMCI::do_unloading(): 3478 alive 0.616ms
>>>>>>>>> [1456.769s][1554230616324ms][info ][gc,phases ] GC(3223) Phase 1: Mark live objects 368.643ms
>>>>>>>>>
>>>>>>>>> [1806.139s][1554230965694ms][info ][gc,start ] GC(4014) Pause Remark
>>>>>>>>> [1806.161s][1554230965716ms][info ][gc ] GC(4014) JVMCI::do_unloading(): 3478 alive 0.000ms
>>>>>>>>> [1806.163s][1554230965717ms][info ][gc ] GC(4014) Pause Remark 1305M->1177M(2772M) 23.190ms
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4/1/19 12:34 AM, Stefan Karlsson wrote:
>>>>>>>>>> On 2019-03-29 17:55, Vladimir Kozlov wrote:
>>>>>>>>>>> Stefan,
>>>>>>>>>>>
>>>>>>>>>>> Do you have a test (and flags) which can allow me to measure effect of this code on G1 remark pause?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -Xlog:gc prints the remark times:
>>>>>>>>>> [4,296s][info][gc ] GC(89) Pause Remark 4M->4M(28M) 36,412ms
>>>>>>>>>>
>>>>>>>>>> StefanK
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Vladimir
>>>>>>>>>>>
>>>>>>>>>>> On 3/29/19 12:36 AM, Stefan Karlsson wrote:
>>>>>>>>>>>> On 2019-03-29 03:07, Vladimir Kozlov wrote:
>>>>>>>>>>>>> Hi Stefan,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I collected some data on MetadataHandleBlock.
>>>>>>>>>>>>>
>>>>>>>>>>>>> First, do_unloading() code is executed only when class_unloading_occurred is 'true' - it is rare case. It
>>>>>>>>>>>>> should not affect normal G1 remark pause.
>>>>>>>>>>>>
>>>>>>>>>>>> It's only rare for applications that don't do dynamic class loading and unloading. The applications that do,
>>>>>>>>>>>> will be affected.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Second, I run a test with -Xcomp. I got about 10,000 compilations by Graal and next data at the end of
>>>>>>>>>>>>> execution:
>>>>>>>>>>>>>
>>>>>>>>>>>>> max_blocks = 232
>>>>>>>>>>>>> max_handles_per_block = 32 (since handles array has 32 elements)
>>>>>>>>>>>>> max_total_alive_values = 4631
>>>>>>>>>>>>
>>>>>>>>>>>> OK. Thanks for the info.
>>>>>>>>>>>>
>>>>>>>>>>>> StefanK
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 3/28/19 2:44 PM, Vladimir Kozlov wrote:
>>>>>>>>>>>>>> Thank you, Stefan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 3/28/19 12:54 PM, Stefan Karlsson wrote:
>>>>>>>>>>>>>>> Hi Vladimir,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I started to check the GC code.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ========================================================================
>>>>>>>>>>>>>>> I see that you've added guarded includes in the middle of the include list:
>>>>>>>>>>>>>>> #include "gc/shared/strongRootsScope.hpp"
>>>>>>>>>>>>>>> #include "gc/shared/weakProcessor.hpp"
>>>>>>>>>>>>>>> + #if INCLUDE_JVMCI
>>>>>>>>>>>>>>> + #include "jvmci/jvmci.hpp"
>>>>>>>>>>>>>>> + #endif
>>>>>>>>>>>>>>> #include "oops/instanceRefKlass.hpp"
>>>>>>>>>>>>>>> #include "oops/oop.inline.hpp"
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The style we use is to put these conditional includes at the end of the include lists.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> okay
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ========================================================================
>>>>>>>>>>>>>>> Could you also change the following:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> + #if INCLUDE_JVMCI
>>>>>>>>>>>>>>> + // Clean JVMCI metadata handles.
>>>>>>>>>>>>>>> + JVMCI::do_unloading(is_alive_closure(), purged_class);
>>>>>>>>>>>>>>> + #endif
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> to:
>>>>>>>>>>>>>>> + // Clean JVMCI metadata handles.
>>>>>>>>>>>>>>> + JVMCI_ONLY(JVMCI::do_unloading(is_alive_closure(), purged_class);)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> to get rid of some of the line noise in the GC files.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> okay
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ========================================================================
>>>>>>>>>>>>>>> In the future we will need version of JVMCI::do_unloading that supports concurrent cleaning for ZGC.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, we need to support concurrent cleaning in a future.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ========================================================================
>>>>>>>>>>>>>>> What's the performance impact for G1 remark pause with this serial walk over the MetadataHandleBlock?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 3275 void G1CollectedHeap::complete_cleaning(BoolObjectClosure* is_alive,
>>>>>>>>>>>>>>> 3276 bool class_unloading_occurred) {
>>>>>>>>>>>>>>> 3277 uint num_workers = workers()->active_workers();
>>>>>>>>>>>>>>> 3278 ParallelCleaningTask unlink_task(is_alive, num_workers, class_unloading_occurred, false);
>>>>>>>>>>>>>>> 3279 workers()->run_task(&unlink_task);
>>>>>>>>>>>>>>> 3280 #if INCLUDE_JVMCI
>>>>>>>>>>>>>>> 3281 // No parallel processing of JVMCI metadata handles for now.
>>>>>>>>>>>>>>> 3282 JVMCI::do_unloading(is_alive, class_unloading_occurred);
>>>>>>>>>>>>>>> 3283 #endif
>>>>>>>>>>>>>>> 3284 }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There should not be impact if Graal is not used. Only cost of call (which most likely is inlined in
>>>>>>>>>>>>>> product VM) and check:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://hg.openjdk.java.net/metropolis/dev/file/530fc1427d02/src/hotspot/share/jvmci/jvmciRuntime.cpp#l1237
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If Graal is used it should not have big impact since these metadata has regular pattern (32 handles per
>>>>>>>>>>>>>> array and array per MetadataHandleBlock block which are linked in list) and not large.
>>>>>>>>>>>>>> If there will be noticeable impact - we will work on it as you suggested by using ParallelCleaningTask.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ========================================================================
>>>>>>>>>>>>>>> Did you consider adding it as a task for one of the worker threads to execute in ParallelCleaningTask?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> See how other tasks are claimed by one worker:
>>>>>>>>>>>>>>> void KlassCleaningTask::work() {
>>>>>>>>>>>>>>> ResourceMark rm;
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> // One worker will clean the subklass/sibling klass tree.
>>>>>>>>>>>>>>> if (claim_clean_klass_tree_task()) {
>>>>>>>>>>>>>>> Klass::clean_subklass_tree();
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> These changes were ported from JDK8u based changes in graal-jvmci-8 and there are no ParallelCleaningTask
>>>>>>>>>>>>>> in JDK8.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Your suggestion is interesting and I agree that we should investigate it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ========================================================================
>>>>>>>>>>>>>>> In MetadataHandleBlock::do_unloading:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> + if (klass->class_loader_data()->is_unloading()) {
>>>>>>>>>>>>>>> + // This needs to be marked so that it's no longer scanned
>>>>>>>>>>>>>>> + // but can't be put on the free list yet. The
>>>>>>>>>>>>>>> + // ReferenceCleaner will set this to NULL and
>>>>>>>>>>>>>>> + // put it on the free list.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I couldn't find the ReferenceCleaner in the patch or in the source. Where can I find this code?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think it is typo (I will fix it) - it references new HandleCleaner class:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HandleCleaner.java.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> StefanK
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 2019-03-28 20:15, Vladimir Kozlov wrote:
>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8220623
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Update JVMCI to support pre-compiled as shared library Graal.
>>>>>>>>>>>>>>>> Using aoted Graal can offers benefits including:
>>>>>>>>>>>>>>>> - fast startup
>>>>>>>>>>>>>>>> - compile time similar to native JIt compilers (C2)
>>>>>>>>>>>>>>>> - memory usage disjoint from the application Java heap
>>>>>>>>>>>>>>>> - no profile pollution of JDK code used by the application
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This is JDK13 port of JVMCI changes done in graal-jvmci-8 [1] up to date.
>>>>>>>>>>>>>>>> Changes were collected in Metropolis repo [2] and tested there.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Changes we reviewed by Oracle Labs (authors of JVMCI and Graal) and our compiler group.
>>>>>>>>>>>>>>>> Changes in shared code are guarded by #if INCLUDE_JVMCI and JVMCI flags.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I ran tier1-tier8 (which includes HotSpot and JDK tests) and it was clean. In this set Graal was tested
>>>>>>>>>>>>>>>> only in tier3.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And I ran all hs-tier3-graal .. hs-tier8-graal Graal tests available in our system. Several issue were
>>>>>>>>>>>>>>>> found which were present before these changes.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [1] https://github.com/graalvm/graal-jvmci-8/commit/49ff2045fb603e35516a3a427d8023c00e1607af
>>>>>>>>>>>>>>>> [2] http://hg.openjdk.java.net/metropolis/dev/
>>>>>>>>>>>>>>>
>>>>>
>>>>
>
More information about the hotspot-dev
mailing list