On Mon, 13 Jun 2022 17:02:44 GMT, Coleen Phillimore wrote:
> Use a native JVM monitor and state for mutual exclusion for class linking and
> initialization. See CR for more details.
> Tested with tier1-8. tiers 1-4 on Oracle supported platforms and 5-8 on
> linux-x64-debug. The
On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in the
On Mon, 25 Apr 2022 19:36:49 GMT, Stefan Karlsson wrote:
>> src/hotspot/share/oops/instanceKlass.cpp line 441:
>>
>>> 439:
>>> 440: // Allocation
>>> 441: if (parser.is_java_lang_ref_Reference_subclass()) {
>>
>> I'm having a really hard time understanding this. java.lang.Reference now
>
On Fri, 22 Apr 2022 09:43:45 GMT, Albert Mingkun Yang wrote:
>> Simple rename and some comments update.
>>
>> Test: build
>
> Albert Mingkun Yang has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Remove REF_ enum for java.lang.ref.Reference
On Fri, 22 Apr 2022 09:43:45 GMT, Albert Mingkun Yang wrote:
>> Simple rename and some comments update.
>>
>> Test: build
>
> Albert Mingkun Yang has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Remove REF_ enum for java.lang.ref.Reference
On Fri, 15 Apr 2022 07:40:04 GMT, Magnus Ihse Bursie wrote:
> I ran `codespell` on hotspot, and accepted those changes where it indeed
> discovered real typos.
>
> You'd be surprised over the many implementions of instrinsics and other
> intructions accross all archtectures I've encounted, so
On Mon, 11 Apr 2022 11:55:33 GMT, Roman Kennke wrote:
>> JVMTI heap walking marks objects in order to track which have been visited
>> already. In order to do that, it uses bits in the object header. Those are
>> the same bits that are also used by some GCs to mark objects (the lowest two
>> b
On Thu, 7 Apr 2022 18:28:42 GMT, Roman Kennke wrote:
>> JVMTI heap walking marks objects in order to track which have been visited
>> already. In order to do that, it uses bits in the object header. Those are
>> the same bits that are also used by some GCs to mark objects (the lowest two
>> bi
On Thu, 7 Apr 2022 18:28:42 GMT, Roman Kennke wrote:
>> JVMTI heap walking marks objects in order to track which have been visited
>> already. In order to do that, it uses bits in the object header. Those are
>> the same bits that are also used by some GCs to mark objects (the lowest two
>> bi
On Fri, 4 Mar 2022 17:12:51 GMT, Alex Menkov wrote:
>> JDK-8238048 (fixed in jdk15) moved major_version, minor_version,
>> generic_signature_index and source_file_name_index from InstanceKlass to
>> ConstantPool.
>> We still have some incorrect code in CP merge during class redefinition.
>>
>>
On Thu, 3 Mar 2022 15:07:05 GMT, Alex Menkov wrote:
> JDK-8238048 (fixed in jdk15) moved major_version, minor_version,
> generic_signature_index and source_file_name_index from InstanceKlass to
> ConstantPool.
> We still have some incorrect code in CP merge during class redefinition.
>
> rewri
On Thu, 17 Feb 2022 18:24:47 GMT, Alex Menkov wrote:
>> ClassLoaderDataGraph::classes_do description says:
>> // Walking classes through the ClassLoaderDataGraph include array classes.
>> So do_load_class callback should not dump arrays for the classes and dumper
>> doesn't need to call Universe
On Thu, 17 Feb 2022 12:45:10 GMT, Alex Menkov wrote:
>> src/hotspot/share/services/heapDumper.cpp line 2305:
>>
>>> 2303: ClassLoaderDataGraph::classes_do(&locked_dump_class);
>>> 2304: }
>>> 2305: Universe::basic_type_classes_do(&do_basic_type_array_class_dump);
>>
>> If this is
On Mon, 14 Feb 2022 13:05:52 GMT, Alex Menkov wrote:
>> ClassLoaderDataGraph::classes_do description says:
>> // Walking classes through the ClassLoaderDataGraph include array classes.
>> So do_load_class callback should not dump arrays for the classes and dumper
>> doesn't need to call Universe
On Tue, 21 Dec 2021 20:51:04 GMT, Coleen Phillimore wrote:
> This is the fix for https://github.com/openjdk/jdk/pull/6900 retargeted to
> JDK 18.
>
> Thanks to @stefank and @fisk for the diagnosis. ZGC is looking at metadata in
> unloaded nmethods, but redefinition doesn'
On Tue, 21 Dec 2021 20:51:04 GMT, Coleen Phillimore wrote:
> This is the fix for https://github.com/openjdk/jdk/pull/6900 retargeted to
> JDK 18.
>
> Thanks to @stefank and @fisk for the diagnosis. ZGC is looking at metadata in
> unloaded nmethods, but redefinition doesn'
On Mon, 13 Dec 2021 23:14:43 GMT, Coleen Phillimore wrote:
> This change makes VM_Version_Ext part of VM_Version (the platform dependent
> part) and moves some duplicated code. x86 had the most code in
> VM_Version_Ext, so the most code moved there. There might be some unneeded
&g
On Tue, 14 Dec 2021 17:42:00 GMT, Coleen Phillimore wrote:
>> This change makes VM_Version_Ext part of VM_Version (the platform dependent
>> part) and moves some duplicated code. x86 had the most code in
>> VM_Version_Ext, so the most code moved there. There migh
On Tue, 14 Dec 2021 17:42:00 GMT, Coleen Phillimore wrote:
>> This change makes VM_Version_Ext part of VM_Version (the platform dependent
>> part) and moves some duplicated code. x86 had the most code in
>> VM_Version_Ext, so the most code moved there. There migh
On Tue, 14 Dec 2021 16:24:10 GMT, Coleen Phillimore wrote:
>> src/hotspot/os/linux/os_perf_linux.cpp line 929:
>>
>>> 927: bool CPUInformationInterface::initialize() {
>>> 928: _cpu_info = new CPUInformation();
>>> 929: VM_Version::initialize_cpu_i
o,linux-x86-zero-debug
>
> Ran JFR tests manually (it uses os_perf* CPUInformationInterface code).
Coleen Phillimore has updated the pull request incrementally with one
additional commit since the last revision:
Added an initialization assert.
-
Changes:
- all: https://git.ope
On Mon, 13 Dec 2021 23:14:43 GMT, Coleen Phillimore wrote:
> This change makes VM_Version_Ext part of VM_Version (the platform dependent
> part) and moves some duplicated code. x86 had the most code in
> VM_Version_Ext, so the most code moved there. There might be some unneeded
&g
On Tue, 14 Dec 2021 02:32:54 GMT, David Holmes wrote:
>> This change makes VM_Version_Ext part of VM_Version (the platform dependent
>> part) and moves some duplicated code. x86 had the most code in
>> VM_Version_Ext, so the most code moved there. There might be some unneeded
>> functions but
This change makes VM_Version_Ext part of VM_Version (the platform dependent
part) and moves some duplicated code. x86 had the most code in VM_Version_Ext,
so the most code moved there. There might be some unneeded functions but I
didn't want to remove them with this change.
Tier1 (tier2-4 test
On Tue, 30 Nov 2021 02:37:47 GMT, Coleen Phillimore wrote:
> This change seems to keep the test case in the bug from crashing in the
> ResourceMark destructor. We have a ResourceMark during stack walking in
> AsyncGetCallTrace. Also RegisterMap during jvmti shouldn't pro
On Tue, 30 Nov 2021 07:18:22 GMT, Thomas Stuefe wrote:
> This bypasses the currently observed problem, but we still have a
> fundamentally unsafe mechanism in use here. :(
Definitely. I think having some assert code that verifies that we don't do
anything "unsafe" while in AsyncGetCallTrace m
This change seems to keep the test case in the bug from crashing in the
ResourceMark destructor. We have a ResourceMark during stack walking in
AsyncGetCallTrace. Also RegisterMap during jvmti shouldn't process oops, fix
care of @fisk.
Testing tier1-6 in progress.
-
Commit messag
On Fri, 12 Nov 2021 15:08:24 GMT, Patricio Chilano Mateo
wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add _is_running initialization.
>
> src/hotspot/share/jfr/dcmd/jf
On Wed, 10 Nov 2021 17:16:29 GMT, Coleen Phillimore wrote:
> JNI Local handles can only be created by JavaThread (there's an assert in
> make_local) but the fields are added to Thread.
> Move the fields to JavaThread and adding JavaThread* argument.
> Also, the global freelist
On Thu, 11 Nov 2021 13:58:06 GMT, Coleen Phillimore wrote:
>> JNI Local handles can only be created by JavaThread (there's an assert in
>> make_local) but the fields are added to Thread.
>> Move the fields to JavaThread and adding JavaThread* argument.
>> Also, t
e with a JNIHandleMark object, moved from jvmci code.
> The commits are separate to help reviewing, but the entire change has been
> tested together with tier1-6.
> The commits in this change have been performance tested individually and
> together with no meaningful differences fro
On Wed, 10 Nov 2021 17:16:29 GMT, Coleen Phillimore wrote:
> JNI Local handles can only be created by JavaThread (there's an assert in
> make_local) but the fields are added to Thread.
> Move the fields to JavaThread and adding JavaThread* argument.
> Also, the global freelist
e with a JNIHandleMark object, moved from jvmci code.
> The commits are separate to help reviewing, but the entire change has been
> tested together with tier1-6.
> The commits in this change have been performance tested individually and
> together with no meaningful differences fro
On Thu, 11 Nov 2021 06:52:45 GMT, David Holmes wrote:
>> JNI Local handles can only be created by JavaThread (there's an assert in
>> make_local) but the fields are added to Thread.
>> Move the fields to JavaThread and adding JavaThread* argument.
>> Also, the global freelist isn't very useful n
On Thu, 11 Nov 2021 06:35:59 GMT, David Holmes wrote:
>> JNI Local handles can only be created by JavaThread (there's an assert in
>> make_local) but the fields are added to Thread.
>> Move the fields to JavaThread and adding JavaThread* argument.
>> Also, the global freelist isn't very useful n
JNI Local handles can only be created by JavaThread (there's an assert in
make_local) but the fields are added to Thread.
Move the fields to JavaThread and adding JavaThread* argument.
Also, the global freelist isn't very useful now that global JNI handles don't
use JNIHandleBlock, so the locking
On Mon, 8 Nov 2021 02:42:58 GMT, Denghui Dong wrote:
>> Hi,
>>
>> Could I have a review of this fix that corrects the oop size value of
>> dtrace_object_alloc(_base).
>>
>> JDK-8039904 added a new parameter 'size' to
>> SharedRuntime::dtrace_object_alloc and dtrace_object_alloc_base, but didn
On Fri, 5 Nov 2021 20:46:21 GMT, Daniel D. Daugherty wrote:
>> JvmtiThreadState objects point to JavaThread and vice versa, so I still
>> don't see why you don't protect the first element.
>
> I've written up a rather long analysis about how the use of
> `JvmtiThreadState_lock`
> in `JvmtiEvent
On Fri, 5 Nov 2021 15:43:37 GMT, Daniel D. Daugherty wrote:
>> A fix to reduce ThreadsListHandle overhead in relation to handshakes and
>> we add sanity checks for ThreadsListHandles higher in the call stack.
>>
>> This fix was tested with Mach5 Tier[1-8]; Tier8 is still running.
>
> Daniel D. D
On Fri, 5 Nov 2021 15:38:27 GMT, Daniel D. Daugherty wrote:
>> Should the ThreadsListHandle protect JvmtiThreadState::first also? If
>> state->next() needs it why doesn't the first entry need this? There's no
>> atomic load on the _head field.
>
> The `ThreadsListHandle` protects `JavaThread`
On Mon, 1 Nov 2021 15:59:58 GMT, Daniel D. Daugherty wrote:
>> Update: I've added comments to WB_HandshakeReadMonitors() and
>> WB_HandshakeWalkStack() to clarify their expectations.
>
> Update again: I took a closer look at `WB_AsyncHandshakeWalkStack()`,
> `WB_HandshakeReadMonitors()` and `WB_H
On Thu, 4 Nov 2021 17:02:59 GMT, Daniel D. Daugherty wrote:
>> Sorry I missed that line 463 is still within the else from line 447.
>>
>> Thread::current() is a compiler-defined thread-local access so should be
>> relatively cheap these days, but I have no numbers.
>
> I'm really tempted to go
On Fri, 15 Oct 2021 21:34:50 GMT, Daniel D. Daugherty
wrote:
>> src/hotspot/share/prims/jvmtiEventController.cpp line 623:
>>
>>> 621: // If we have a JvmtiThreadState, then we've reached the point
>>> where
>>> 622: // threads can exist so create a ThreadsListHandle to protect them.
>
On Tue, 2 Nov 2021 17:26:41 GMT, Daniel D. Daugherty wrote:
>> A fix to reduce ThreadsListHandle overhead in relation to handshakes and
>> we add sanity checks for ThreadsListHandles higher in the call stack.
>>
>> This fix was tested with Mach5 Tier[1-8]; Tier8 is still running.
>
> Daniel D. D
On Thu, 4 Nov 2021 13:25:14 GMT, Thomas Stuefe wrote:
> `VM.metaspace`, `VM.classloaders` and `VM.class_hierarchy` all print out
> reflection invocation targets for delegating reflection class loaders. Post
> JEP 416 we don't use DelegatingClassLoaders anymore.
>
> This patch removes the displ
On Tue, 2 Nov 2021 19:25:40 GMT, Leo Korinth wrote:
>> HeapDumper does a lot of unneeded casts. Some arguments should be const.
>> Headers are not correctly sorted. Comment about identifier size on Windows
>> and Solaris is not true.
>>
>> First I cleaned up casting in the "union casting", but
On Mon, 25 Oct 2021 12:51:32 GMT, Coleen Phillimore wrote:
> The Mutex destructor isn't called for the MDO lock. We found this leak with
> crashes for the patch to print all mutex locks on error, which is now
> withdrawn. It was easily reproduced with that patch. It
On Tue, 26 Oct 2021 11:43:42 GMT, Coleen Phillimore wrote:
>> The Mutex destructor isn't called for the MDO lock. We found this leak with
>> crashes for the patch to print all mutex locks on error, which is now
>> withdrawn. It was easily reproduced with that p
On Mon, 25 Oct 2021 23:21:02 GMT, Serguei Spitsyn wrote:
>> Yes, I think that combining release_C_heap_structures and
>> release_C_heap_structures_internal into single release_C_heap_structures
>> with a default parameter will simplify code a little bit. But I'm not sure
>> it is that importan
th that patch though and it passes tier1-6,
Coleen Phillimore has updated the pull request incrementally with one
additional commit since the last revision:
Move constant pool release_C_heap_structures to the end.
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6105/
On Mon, 25 Oct 2021 23:09:03 GMT, Serguei Spitsyn wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add parameter to release_C_heap_structures.
>
> src/hotspot/share/oops/instanceK
th that patch though and it passes tier1-6,
Coleen Phillimore has updated the pull request incrementally with one
additional commit since the last revision:
Add parameter to release_C_heap_structures.
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6105/
On Mon, 25 Oct 2021 22:16:05 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/oops/instanceKlass.cpp line 2692:
>>
>>> 2690:
>>> 2691: // Called also by InstanceKlass::deallocate_contents
>>> 2692: void InstanceKlass::release_C_heap_structures_internal(
On Mon, 25 Oct 2021 21:33:33 GMT, David Holmes wrote:
>> The Mutex destructor isn't called for the MDO lock. We found this leak with
>> crashes for the patch to print all mutex locks on error, which is now
>> withdrawn. It was easily reproduced with that patch. It is not easily
>> reproduce
The Mutex destructor isn't called for the MDO lock. We found this leak with
crashes for the patch to print all mutex locks on error, which is now
withdrawn. It was easily reproduced with that patch. It is not easily
reproduced otherwise.
I tested this change with that patch though and it pass
On Tue, 19 Oct 2021 10:05:15 GMT, Markus Grönlund wrote:
>> Greetings,
>>
>> This fixes the issue seen in testing when accessing an oop as part of
>> unloading (introduced with
>> [JDK-8266936](https://bugs.openjdk.java.net/browse/JDK-8266936)).
>>
>> Instead, oop accesses will be done outsid
On Fri, 15 Oct 2021 06:45:02 GMT, David Holmes wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8249004.cr1.patch
>
> src/hotspot/share/runtime/thread.cpp line 1771:
>
>> 1769: guarantee(Thread::is_JavaThr
On Thu, 14 Oct 2021 16:03:28 GMT, Daniel D. Daugherty
wrote:
>> A fix to reduce ThreadsListHandle overhead in relation to handshakes and
>> we add sanity checks for ThreadsListHandles higher in the call stack.
>>
>> This fix was tested with Mach5 Tier[1-8]; Tier8 is still running.
>
> Daniel D.
On Fri, 15 Oct 2021 09:27:54 GMT, Markus Grönlund wrote:
>> Greetings,
>>
>> Object.finalize() was deprecated in JDK9. There is an ongoing effort to
>> replace and mitigate Object.finalize() uses in the JDK libraries; please see
>> https://bugs.openjdk.java.net/browse/JDK-8253568 for more info
On Thu, 14 Oct 2021 21:58:42 GMT, Coleen Phillimore wrote:
>> "Since you remove entries on unloading, I don't see any reason to have any
>> concurrent cleanup."
>> Thank you, that is true. The only concurrent work required will be to grow
>> the table.
&g
On Mon, 13 Sep 2021 10:54:18 GMT, Markus Grönlund wrote:
>> src/hotspot/share/services/finalizerService.cpp line 44:
>>
>>> 42: _ik(ik),
>>> 43: _objects_on_heap(0),
>>> 44: _total_finalizers_run(0) {}
>>
>> Is this hashtable for every InstanceKlass that defines a finalizer? How
>
On Wed, 13 Oct 2021 18:03:25 GMT, Markus Grönlund wrote:
>> Greetings,
>>
>> Object.finalize() was deprecated in JDK9. There is an ongoing effort to
>> replace and mitigate Object.finalize() uses in the JDK libraries; please see
>> https://bugs.openjdk.java.net/browse/JDK-8253568 for more info
On Fri, 8 Oct 2021 00:48:05 GMT, David Holmes wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix overlap error message printing and add a test.
>
> test/hotspot/gtest/r
On Thu, 7 Oct 2021 15:28:31 GMT, Coleen Phillimore wrote:
>> Also fixes: 8273956: Add checking for rank values
>>
>> This change does 3 things. I could separate them but this has all been
>> tested together and most of the change is mechanical. The first is a simp
On Wed, 6 Oct 2021 23:27:17 GMT, Coleen Phillimore wrote:
> Also fixes: 8273956: Add checking for rank values
>
> This change does 3 things. I could separate them but this has all been
> tested together and most of the change is mechanical. The first is a simple
> re
ot
> unmanageable. There are actually not many nested Mutex.
>
> This is the last of the planned subtasks for Mutex ranking cleanup. If you
> have other ideas or suggestions, please let me know.
>
> Tested with tier1-8 at one point in time and just retested with tier1-
On Thu, 7 Oct 2021 15:59:42 GMT, Patricio Chilano Mateo
wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix overlap error message printing and add a test.
>
> LGTM!
>
>
ot
> unmanageable. There are actually not many nested Mutex.
>
> This is the last of the planned subtasks for Mutex ranking cleanup. If you
> have other ideas or suggestions, please let me know.
>
> Tested with tier1-8 at one point in time and just retested with tier1-
On Wed, 6 Oct 2021 23:27:17 GMT, Coleen Phillimore wrote:
> Also fixes: 8273956: Add checking for rank values
>
> This change does 3 things. I could separate them but this has all been
> tested together and most of the change is mechanical. The first is a simple
> re
On Wed, 6 Oct 2021 23:27:17 GMT, Coleen Phillimore wrote:
> Also fixes: 8273956: Add checking for rank values
>
> This change does 3 things. I could separate them but this has all been
> tested together and most of the change is mechanical. The first is a simple
> re
8273956: Add checking for rank values
This change does 3 things. I could separate them but this has all been tested
together and most of the change is mechanical. The first is a simple rename of
nonleaf => safepoint. The second change is to add the enum class Rank which
only allows subtracti
On Fri, 24 Sep 2021 13:13:39 GMT, Lin Zang wrote:
> The root cause for crash in ZGC is that the JNIHandles are processed before
> object iteration. And ZGC would update the JNIHandles at object iteration
> with read barrier. So the crash is cause by accessing the invalid address
> which can be
On Fri, 24 Sep 2021 15:05:33 GMT, Lin Zang wrote:
>> yes
>> void Mutex::check_no_safepoint_state(Thread* thread) {
>>check_block_state(thread);
>>assert(!thread->is_active_Java_thread() || _safepoint_check_required
>> != _safepoint_check_always,
>> "This lock sh
On Fri, 24 Sep 2021 14:05:48 GMT, Lin Zang wrote:
>> I think it may be because this is actually not a JavaThread. So the assert
>> in `Mutex::check_no_safepoint_state` would pass.
>> Moreover, I have tried to use `PaddedMonitor(Mutex::nosafepoint,
>> "ParallelHProfWriter_lock", Mutex::_safepoi
On Fri, 24 Sep 2021 13:13:39 GMT, Lin Zang wrote:
> The root cause for crash in ZGC is that the JNIHandles are processed before
> object iteration. And ZGC would update the JNIHandles at object iteration
> with read barrier. So the crash is cause by accessing the invalid address
> which can be
On Mon, 13 Sep 2021 17:12:49 GMT, Markus Grönlund wrote:
>> Greetings,
>>
>> Object.finalize() was deprecated in JDK9. There is an ongoing effort to
>> replace and mitigate Object.finalize() uses in the JDK libraries; please see
>> https://bugs.openjdk.java.net/browse/JDK-8253568 for more info
On Mon, 20 Sep 2021 23:32:12 GMT, David Holmes wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add comment about ThreadSMRDelete_lock
>
> So there is more to this than just
On Fri, 17 Sep 2021 11:50:22 GMT, Coleen Phillimore wrote:
> This change removes the special ranking and folds it into nosafepoint. You
> have to look at commit #3 to see this actual part of the change that doesn't
> include JDK-8273915.
> This passes tier1-6 also.
This pul
On Wed, 22 Sep 2021 03:57:21 GMT, Daniel D. Daugherty
wrote:
>> A trivial fix to reduce ThreadListHandle overhead in relation to handshakes.
>>
>> This refactoring was tested with Mach5 Tier[1-3].
>
> Daniel D. Daugherty has updated the pull request with a new target base due
> to a merge or a
On Tue, 21 Sep 2021 21:50:27 GMT, Patricio Chilano Mateo
wrote:
>> Coleen Phillimore has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains six commits:
>>
>> - Remove blank line.
>> - Merge branc
> This change removes the special ranking and folds it into nosafepoint. You
> have to look at commit #3 to see this actual part of the change that doesn't
> include JDK-8273915.
> This passes tier1-6 also.
Coleen Phillimore has updated the pull request incrementally wit
On Tue, 21 Sep 2021 12:07:06 GMT, Coleen Phillimore wrote:
>> This change removes the special ranking and folds it into nosafepoint. You
>> have to look at commit #3 to see this actual part of the change that doesn't
>> include JDK-8273915.
>> This passes tier1-
> This change removes the special ranking and folds it into nosafepoint. You
> have to look at commit #3 to see this actual part of the change that doesn't
> include JDK-8273915.
> This passes tier1-6 also.
Coleen Phillimore has updated the pull request with a new target bas
On Mon, 20 Sep 2021 22:54:19 GMT, Coleen Phillimore wrote:
>> This change removes the special ranking and folds it into nosafepoint. You
>> have to look at commit #3 to see this actual part of the change that doesn't
>> include JDK-8273915.
>> This passes tier1-
On Thu, 16 Sep 2021 17:11:30 GMT, Coleen Phillimore wrote:
> Partition safepoint checking and nonchecking lock ranks. The nonchecking
> locks are always lower ranked than the safepoint checking locks because they
> cannot block.
>
> This moves some leaf locks to 'n
On Mon, 20 Sep 2021 20:16:03 GMT, Coleen Phillimore wrote:
>> Partition safepoint checking and nonchecking lock ranks. The nonchecking
>> locks are always lower ranked than the safepoint checking locks because they
>> cannot block.
>>
>> This moves some leaf l
> This change removes the special ranking and folds it into nosafepoint. You
> have to look at commit #3 to see this actual part of the change that doesn't
> include JDK-8273915.
> This passes tier1-6 also.
Coleen Phillimore has updated the pull request incrementally wit
On Fri, 17 Sep 2021 11:50:22 GMT, Coleen Phillimore wrote:
> This change removes the special ranking and folds it into nosafepoint. You
> have to look at commit #3 to see this actual part of the change that doesn't
> include JDK-8273915.
> This passes tier1-6 also.
All the
On Mon, 20 Sep 2021 20:16:03 GMT, Coleen Phillimore wrote:
>> Partition safepoint checking and nonchecking lock ranks. The nonchecking
>> locks are always lower ranked than the safepoint checking locks because they
>> cannot block.
>>
>> This moves some leaf l
Tested with tier1-6 and built and run tier1 tests with shenandoah locally.
Coleen Phillimore has updated the pull request incrementally with one
additional commit since the last revision:
Add comment and change enum name to Rank.
-
Changes:
- all: https://git.openjdk.java.net/
On Mon, 20 Sep 2021 13:35:29 GMT, Coleen Phillimore wrote:
>> Partition safepoint checking and nonchecking lock ranks. The nonchecking
>> locks are always lower ranked than the safepoint checking locks because they
>> cannot block.
>>
>> This moves some leaf l
On Mon, 20 Sep 2021 18:15:44 GMT, Ioi Lam wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove 'safepoint' rank, now unused.
>
> src/hotspot/share/runtime/mut
On Fri, 17 Sep 2021 11:50:22 GMT, Coleen Phillimore wrote:
> This change removes the special ranking and folds it into nosafepoint. You
> have to look at commit #3 to see this actual part of the change that doesn't
> include JDK-8273915.
> This passes tier1-6 also.
Thanks fo
Tested with tier1-6 and built and run tier1 tests with shenandoah locally.
Coleen Phillimore has updated the pull request incrementally with one
additional commit since the last revision:
Remove 'safepoint' rank, now unused.
-
Changes:
- all: https://git.openjdk
On Mon, 20 Sep 2021 00:08:11 GMT, David Holmes wrote:
>> Partition safepoint checking and nonchecking lock ranks. The nonchecking
>> locks are always lower ranked than the safepoint checking locks because they
>> cannot block.
>>
>> This moves some leaf locks to 'nosafepoint' rank and corrects
On Thu, 16 Sep 2021 17:11:30 GMT, Coleen Phillimore wrote:
> Partition safepoint checking and nonchecking lock ranks. The nonchecking
> locks are always lower ranked than the safepoint checking locks because they
> cannot block.
>
> This moves some leaf locks to 'n
On Mon, 13 Sep 2021 17:12:49 GMT, Markus Grönlund wrote:
>> Greetings,
>>
>> Object.finalize() was deprecated in JDK9. There is an ongoing effort to
>> replace and mitigate Object.finalize() uses in the JDK libraries; please see
>> https://bugs.openjdk.java.net/browse/JDK-8253568 for more info
This change removes the special ranking and folds it into nosafepoint. You
have to look at commit #3 to see this actual part of the change that doesn't
include JDK-8273915.
This passes tier1-6 also.
-
Commit messages:
- Remove "special" rank.
- Partition safepoint checking and no
Partition safepoint checking and nonchecking lock ranks. The nonchecking locks
are always lower ranked than the safepoint checking locks because they cannot
block.
This moves some leaf locks to 'nosafepoint' rank and corrects relative ranking.
Tested with tier1-6 and built and run tier1 tests w
On Thu, 16 Sep 2021 16:08:39 GMT, Volker Simonis wrote:
> Currently, `OopHandle::release()` is implemented as follows:
>
> inline void OopHandle::release(OopStorage* storage) {
> if (peek() != NULL) {
> // Clear the OopHandle first
> NativeAccess<>::oop_store(_obj, (oop)NULL);
> st
1 - 100 of 1018 matches
Mail list logo
