On Wed, 8 Nov 2023 19:00:53 GMT, Roman Kennke wrote:
> See JBS issue for details.
>
> I basically:
> - took the test-modification and turned it into its own test-case
> - added test runners for lightweight- and legacy-locking, so that we keep
> testing both, no matter what is the default
>
On Thu, 18 Aug 2022 08:18:27 GMT, Axel Boldt-Christmas
wrote:
>> The proposal is to encapsulate the nmethod mark for deoptimization logic in
>> one place and only allow access to the `mark_for_deoptimization` from a
>> closure object:
>> ```C++
>> class DeoptimizationMarkerClosure : StackObj
On Fri, 2 Sep 2022 00:04:17 GMT, John R Rose wrote:
>> Refactor code from inside of CompressedStream into its own unit.
>>
>> This code is likely to be used in future refactorings, such as JDK-8292818
>> (replace 96-bit representation for field metadata with variable-sized
>> streams).
>>
>>
On Fri, 2 Sep 2022 00:04:17 GMT, John R Rose wrote:
>> Refactor code from inside of CompressedStream into its own unit.
>>
>> This code is likely to be used in future refactorings, such as JDK-8292818
>> (replace 96-bit representation for field metadata with variable-sized
>> streams).
>>
>>
On Fri, 2 Sep 2022 00:04:17 GMT, John R Rose wrote:
>> Refactor code from inside of CompressedStream into its own unit.
>>
>> This code is likely to be used in future refactorings, such as JDK-8292818
>> (replace 96-bit representation for field metadata with variable-sized
>> streams).
>>
>>
On Wed, 7 Sep 2022 01:05:38 GMT, John R Rose wrote:
>> Refactor code from inside of CompressedStream into its own unit.
>>
>> This code is likely to be used in future refactorings, such as JDK-8292818
>> (replace 96-bit representation for field metadata with variable-sized
>> streams).
>>
>>
On Thu, 18 Aug 2022 09:32:54 GMT, Axel Boldt-Christmas
wrote:
>> src/hotspot/share/code/compiledMethod.cpp line 128:
>>
>>> 126: if (old_status < new_status) {
>>> 127: if (old_status == not_enqueued) {
>>> 128:
>>>
On Wed, 3 Aug 2022 20:42:59 GMT, Erik Österlund wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Add assertions
>> - Fix marked logic
>> - Erik refactorings
>
> Also, in
On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas wrote:
>> The proposal is to encapsulate the nmethod mark for deoptimization logic in
>> one place and only allow access to the `mark_for_deoptimization` from a
>> closure object:
>> ```C++
>> class DeoptimizationMarkerClosure : StackObj {
On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas wrote:
>> The proposal is to encapsulate the nmethod mark for deoptimization logic in
>> one place and only allow access to the `mark_for_deoptimization` from a
>> closure object:
>> ```C++
>> class DeoptimizationMarkerClosure : StackObj {
On Tue, 28 Mar 2023 10:53:10 GMT, Roman Kennke wrote:
>> src/hotspot/share/runtime/threads.cpp line 1422:
>>
>>> 1420: }
>>> 1421:
>>> 1422: JavaThread* Threads::owning_thread_from_object(ThreadsList * t_list,
>>> oop obj) {
>>
>> Is this thread-safe?
>
> My last commit changed that code to
On Fri, 31 Mar 2023 07:25:48 GMT, Thomas Stuefe wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Use int instead of size_t for cached offsets, to match the uncached offset
>> type and avoid build failures
>
>
On Tue, 11 Apr 2023 19:58:19 GMT, Roman Kennke wrote:
>> The `_base` array is only initialized to nullptr in debug builds. I don't
>> see a release barrier in LockStack::push between the update to _base[] and
>> the update to _top, nor a corresponding acquire barrier when reading.
>>
On Tue, 11 Apr 2023 15:29:16 GMT, Daniel D. Daugherty
wrote:
>> OK. Given that I haven't looked at the rest of the patch, I leave it up to
>> you and the Reviewers to figure out what to do about this code. Cheers.
>
> Given that the race with new lightweight locking is virtually the same as
On Mon, 27 Mar 2023 20:24:14 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of
On Mon, 27 Mar 2023 20:24:14 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of
On Mon, 27 Mar 2023 20:24:14 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of
On Fri, 24 Mar 2023 06:15:31 GMT, David Holmes wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>> - Set condition flags correctly after
On Mon, 27 Mar 2023 20:24:14 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of
On Mon, 27 Mar 2023 20:24:14 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of
On Tue, 2 May 2023 18:38:11 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Fri, 4 Aug 2023 14:37:07 GMT, Coleen Phillimore wrote:
> This patch fixes Wconversion in code in the src/hotspot/share/prims
> directory. Most of the changes correct the types. jfieldID's are created
> with the int offset returned by InstanceKlass::field_offset().
> int
On Fri, 4 Aug 2023 14:37:07 GMT, Coleen Phillimore wrote:
> This patch fixes Wconversion in code in the src/hotspot/share/prims
> directory. Most of the changes correct the types. jfieldID's are created
> with the int offset returned by InstanceKlass::field_offset().
> int
On Fri, 4 Aug 2023 14:37:07 GMT, Coleen Phillimore wrote:
> This patch fixes Wconversion in code in the src/hotspot/share/prims
> directory. Most of the changes correct the types. jfieldID's are created
> with the int offset returned by InstanceKlass::field_offset().
> int
On Fri, 4 Aug 2023 14:37:07 GMT, Coleen Phillimore wrote:
> This patch fixes Wconversion in code in the src/hotspot/share/prims
> directory. Most of the changes correct the types. jfieldID's are created
> with the int offset returned by InstanceKlass::field_offset().
> int
On Fri, 4 Aug 2023 14:37:07 GMT, Coleen Phillimore wrote:
> This patch fixes Wconversion in code in the src/hotspot/share/prims
> directory. Most of the changes correct the types. jfieldID's are created
> with the int offset returned by InstanceKlass::field_offset().
> int
On Fri, 4 Aug 2023 23:24:45 GMT, Coleen Phillimore wrote:
> Why not? It's the same and casts the int where it's needed to be an int.
To me the checked_cast looks less ugly in the initialization vs at the uses
sites, but in this case with only one use it doesn't really matter.
-
PR
On Tue, 27 Jun 2023 12:22:43 GMT, Daniel Jeliński wrote:
> Please review this attempt to fix ignored-qualifiers warning.
>
> Example warnings:
>
> src/hotspot/share/oops/method.hpp:413:19: warning: 'volatile' type qualifier
> on return type has no effect [-Wignored-qualifiers]
>
On Tue, 23 Jan 2024 16:37:35 GMT, Volker Simonis wrote:
>> src/hotspot/share/runtime/init.cpp line 121:
>>
>>> 119: if (AlwaysRecordEvolDependencies) {
>>> 120: JvmtiExport::set_can_hotswap_or_post_breakpoint(true);
>>> 121: JvmtiExport::set_all_dependencies_are_recorded(true);
>>
>>
On Mon, 22 Jan 2024 21:26:41 GMT, Volker Simonis wrote:
>> Currently we don't record dependencies on redefined methods (i.e.
>> `evol_method` dependencies) in JIT compiled methods if none of the
>> `can_redefine_classes`, `can_retransform_classes` or
>> `can_generate_breakpoint_events` JVMTI
On Mon, 11 Dec 2023 22:41:56 GMT, Yi-Fan Tsai wrote:
>> `jcmd Compiler.perfmap` uses the hard-coded file name for a perf map:
>> `/tmp/perf-%d.map`. This change adds an optional argument for specifying a
>> file name.
>>
>> `jcmd PID help Compiler.perfmap` shows the following usage.
>>
>>
On Wed, 24 Jan 2024 14:48:52 GMT, Volker Simonis wrote:
>> Currently we don't record dependencies on redefined methods (i.e.
>> `evol_method` dependencies) in JIT compiled methods if none of the
>> `can_redefine_classes`, `can_retransform_classes` or
>> `can_generate_breakpoint_events` JVMTI
On Thu, 22 Feb 2024 19:38:26 GMT, Kim Barrett wrote:
> Please review this trivial change that renames the file
> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_common/agent_common.h to
> agent_common.hpp.
>
> The #include updates were performed mechanically, and builds would fail if
>
On Tue, 16 Apr 2024 16:09:21 GMT, Vladimir Kozlov wrote:
>> src/hotspot/share/code/nmethod.cpp line 1441:
>>
>>> 1439: int deps_size = align_up((int)dependencies->size_in_bytes(),
>>> oopSize);
>>> 1440: int sum_size = oops_size + metadata_size + deps_size;
>>> 1441:
On Wed, 17 Apr 2024 15:26:52 GMT, Matias Saavedra Silva
wrote:
> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190),
> [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and
> [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic
> operands needed
On Wed, 17 Apr 2024 15:26:52 GMT, Matias Saavedra Silva
wrote:
> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190),
> [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and
> [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic
> operands needed
On Wed, 17 Apr 2024 15:26:52 GMT, Matias Saavedra Silva
wrote:
> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190),
> [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and
> [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic
> operands needed
On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov wrote:
>> This is part of changes which try to reduce size of `nmethod` and `codeblob`
>> data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From
>> 304 to 248 in optimized VM:
>>
>> Statistics
On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov wrote:
>> This is part of changes which try to reduce size of `nmethod` and `codeblob`
>> data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From
>> 304 to 248 in optimized VM:
>>
>> Statistics
On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov wrote:
>> This is part of changes which try to reduce size of `nmethod` and `codeblob`
>> data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From
>> 304 to 248 in optimized VM:
>>
>> Statistics
On Tue, 16 Apr 2024 03:12:48 GMT, Vladimir Kozlov wrote:
>> src/hotspot/share/code/nmethod.hpp line 282:
>>
>>> 280: _has_flushed_dependencies:1, // Used for maintenance of
>>> dependencies (under CodeCache_lock)
>>> 281: _is_unlinked:1, // mark during class
On Tue, 16 Apr 2024 03:06:13 GMT, Vladimir Kozlov wrote:
>> src/hotspot/share/code/nmethod.hpp line 205:
>>
>>> 203: // offsets to find the receiver for non-static native wrapper
>>> frames.
>>> 204: ByteSize _native_receiver_sp_offset;
>>> 205: ByteSize
On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov wrote:
>> This is part of changes which try to reduce size of `nmethod` and `codeblob`
>> data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From
>> 304 to 248 in optimized VM:
>>
>> Statistics
On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov wrote:
>> This is part of changes which try to reduce size of `nmethod` and `codeblob`
>> data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From
>> 304 to 248 in optimized VM:
>>
>> Statistics
On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov wrote:
>> This is part of changes which try to reduce size of `nmethod` and `codeblob`
>> data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From
>> 304 to 248 in optimized VM:
>>
>> Statistics
On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov wrote:
>> This is part of changes which try to reduce size of `nmethod` and `codeblob`
>> data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From
>> 304 to 248 in optimized VM:
>>
>> Statistics
On Fri, 26 Apr 2024 21:36:50 GMT, Vladimir Kozlov wrote:
>> Move immutable nmethod's data from CodeCache to C heap. It includes
>> `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data,
>> speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space
>> in
On Fri, 26 Apr 2024 21:16:03 GMT, Vladimir Kozlov wrote:
> Move immutable nmethod's data from CodeCache to C heap. It includes
> `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data,
> speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space
> in CodeCache.
On Fri, 26 Apr 2024 21:16:03 GMT, Vladimir Kozlov wrote:
> Move immutable nmethod's data from CodeCache to C heap. It includes
> `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data,
> speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space
> in CodeCache.
On Fri, 26 Apr 2024 21:16:03 GMT, Vladimir Kozlov wrote:
> Move immutable nmethod's data from CodeCache to C heap. It includes
> `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data,
> speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space
> in CodeCache.
On Thu, 18 Apr 2024 00:41:03 GMT, Vladimir Kozlov wrote:
>> This is part of changes which try to reduce size of `nmethod` and `codeblob`
>> data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From
>> 304 to 248 in optimized VM:
>>
>> Statistics
On Fri, 26 Apr 2024 21:16:03 GMT, Vladimir Kozlov wrote:
> Move immutable nmethod's data from CodeCache to C heap. It includes
> `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data,
> speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space
> in CodeCache.
On Sun, 28 Apr 2024 07:02:40 GMT, Dean Long wrote:
>> Move immutable nmethod's data from CodeCache to C heap. It includes
>> `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data,
>> speculations`. It amounts for about 30% (optimized VM) of space in Cod
On Sun, 28 Apr 2024 23:37:22 GMT, Vladimir Kozlov wrote:
>> Move immutable nmethod's data from CodeCache to C heap. It includes
>> `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data,
>> speculations`. It amounts for about 30% (optimized VM) of space in CodeCache.
>>
>> Use
On Fri, 12 Apr 2024 14:40:05 GMT, Sergey Nazarkin wrote:
> An alternative for preemptively switching the W^X thread mode on macOS with
> an AArch64 CPU. This implementation triggers the switch in response to the
> SIGBUS signal if the *si_addr* belongs to the CodeCache area. With this
>
On Tue, 6 Feb 2024 22:59:04 GMT, Coleen Phillimore wrote:
> This change creates a new sort of native recursive lock that can be held
> during JNI and Java calls, which can be used for synchronization while
> creating objArrayKlasses at runtime.
>
> Passes tier1-7.
On Tue, 6 Feb 2024 22:59:04 GMT, Coleen Phillimore wrote:
> This change creates a new sort of native recursive lock that can be held
> during JNI and Java calls, which can be used for synchronization while
> creating objArrayKlasses at runtime.
>
> Passes tier1-7.
OK, that makes sense about
On Wed, 6 Mar 2024 23:47:01 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/runtime/mutex.cpp line 537:
>>
>>> 535: // can be called by jvmti by VMThread.
>>> 536: if (current->is_Java_thread()) {
>>> 537: _sem.wait_with_safepoint_check(JavaThread::cast(current));
>>
>> Why
On Tue, 6 Feb 2024 22:59:04 GMT, Coleen Phillimore wrote:
> This change creates a new sort of native recursive lock that can be held
> during JNI and Java calls, which can be used for synchronization while
> creating objArrayKlasses at runtime.
>
> Passes tier1-7.
On Tue, 6 Feb 2024 22:59:04 GMT, Coleen Phillimore wrote:
> This change creates a new sort of native recursive lock that can be held
> during JNI and Java calls, which can be used for synchronization while
> creating objArrayKlasses at runtime.
>
> Passes tier1-7.
Marked as reviewed by dlong
On Thu, 7 Mar 2024 01:38:56 GMT, Coleen Phillimore wrote:
>> This change creates a new sort of native recursive lock that can be held
>> during JNI and Java calls, which can be used for synchronization while
>> creating objArrayKlasses at runtime.
>>
>> Passes tier1-7.
>
> Coleen Phillimore
On Tue, 6 Feb 2024 22:59:04 GMT, Coleen Phillimore wrote:
> This change creates a new sort of native recursive lock that can be held
> during JNI and Java calls, which can be used for synchronization while
> creating objArrayKlasses at runtime.
>
> Passes tier1-7.
Is the caller always a
On Fri, 29 Mar 2024 19:35:45 GMT, Vladimir Kozlov wrote:
> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE
> [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365)
> which was used for AOT [JEP 295](https://openjdk.org/jeps/295)
>
On Thu, 22 Feb 2024 19:38:26 GMT, Kim Barrett wrote:
> Please review this trivial change that renames the file
> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_common/agent_common.h to
> agent_common.hpp.
>
> The #include updates were performed mechanically, and builds would fail if
>
64 matches
Mail list logo