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 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 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 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: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 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 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 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 12:35:54 GMT, Yudi Zheng wrote:
>> Moving array construction within BigInteger.implMultiplyToLen intrinsic
>> candidate to its caller simplifies the intrinsic implementation in JIT
>> compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional
>
On Wed, 17 Apr 2024 12:35:54 GMT, Yudi Zheng wrote:
>> Moving array construction within BigInteger.implMultiplyToLen intrinsic
>> candidate to its caller simplifies the intrinsic implementation in JIT
>> compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional
>
On Wed, 17 Apr 2024 19:45:02 GMT, Dean Long wrote:
>> Yudi Zheng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> address comment.
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4702:
>
On Wed, 17 Apr 2024 12:35:54 GMT, Yudi Zheng wrote:
>> Moving array construction within BigInteger.implMultiplyToLen intrinsic
>> candidate to its caller simplifies the intrinsic implementation in JIT
>> compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional
>
On Wed, 17 Apr 2024 12:35:54 GMT, Yudi Zheng wrote:
>> Moving array construction within BigInteger.implMultiplyToLen intrinsic
>> candidate to its caller simplifies the intrinsic implementation in JIT
>> compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional
>
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 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, 8 Apr 2024 19:11:19 GMT, Scott Gibbons wrote:
>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
>> this change.
>>
>> Overall, making this an intrinsic improves overall
On Sat, 6 Apr 2024 00:13:26 GMT, Scott Gibbons wrote:
>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
>> this change.
>>
>> Overall, making this an intrinsic improves overall
On Wed, 3 Apr 2024 15:15:24 GMT, Scott Gibbons wrote:
>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
>> this change.
>>
>> Overall, making this an intrinsic improves overall
On Wed, 3 Apr 2024 15:15:24 GMT, Scott Gibbons wrote:
>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
>> this change.
>>
>> Overall, making this an intrinsic improves overall
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 Tue, 19 Mar 2024 19:06:36 GMT, Yudi Zheng wrote:
>> Moving array construction within BigInteger.implMultiplyToLen intrinsic
>> candidate to its caller simplifies the intrinsic implementation in JIT
>> compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional
>
On Tue, 19 Mar 2024 19:06:36 GMT, Yudi Zheng wrote:
>> Moving array construction within BigInteger.implMultiplyToLen intrinsic
>> candidate to its caller simplifies the intrinsic implementation in JIT
>> compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional
>
On Tue, 12 Mar 2024 10:44:54 GMT, Yudi Zheng wrote:
> Moving array construction within BigInteger.implMultiplyToLen intrinsic
> candidate to its caller simplifies the intrinsic implementation in JIT
> compiler.
src/hotspot/share/opto/library_call.cpp line 5934:
> 5932: // 'y_start'
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.
Marked as reviewed by dlong
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.
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.
OK, that makes sense about
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 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 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 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 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, 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, 2 Nov 2023 11:07:27 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less
On Wed, 16 Aug 2023 23:56:58 GMT, Coleen Phillimore wrote:
>> Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion
>> warnings in runtime code. This is the last one I'm going to do for runtime
>> for a while.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the
On Wed, 16 Aug 2023 19:16:28 GMT, Coleen Phillimore wrote:
>> Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion
>> warnings in runtime code. This is the last one I'm going to do for runtime
>> for a while.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the
On Wed, 16 Aug 2023 19:16:28 GMT, Coleen Phillimore wrote:
>> Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion
>> warnings in runtime code. This is the last one I'm going to do for runtime
>> for a while.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the
On Wed, 16 Aug 2023 19:16:28 GMT, Coleen Phillimore wrote:
>> Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion
>> warnings in runtime code. This is the last one I'm going to do for runtime
>> for a while.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the
On Thu, 10 Aug 2023 04:04:58 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done
>> with some effort, given that the
On Thu, 10 Aug 2023 04:04:58 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done
>> with some effort, given that the
On Thu, 10 Aug 2023 04:04:58 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done
>> with some effort, given that the
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 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 17:05:55 GMT, Matias Saavedra Silva
wrote:
>> The recent change in
>> [JDK-8301996](https://bugs.openjdk.org/browse/JDK-8301996) added more
>> -Wconversion warnings that are addressed in this patch. The aforementioned
>> change has overlooked inconsistencies with the types
On Thu, 3 Aug 2023 20:53:56 GMT, Matias Saavedra Silva
wrote:
>> The recent change in
>> [JDK-8301996](https://bugs.openjdk.org/browse/JDK-8301996) added more
>> -Wconversion warnings that are addressed in this patch. The aforementioned
>> change has overlooked inconsistencies with the types
On Thu, 3 Aug 2023 19:15:30 GMT, Coleen Phillimore wrote:
>> As far as I've designed it, only the last two bits of the flags are ever set
>> or used. C++ booleans are either 0 or 1 so the higher bits should never be
>> set.
>
> It is only two bits and the only variable here "is_final_shift" is
On Wed, 2 Aug 2023 19:15:24 GMT, Matias Saavedra Silva
wrote:
> The recent change in
> [JDK-8301996](https://bugs.openjdk.org/browse/JDK-8301996) added more
> -Wconversion warnings that are addressed in this patch. The aforementioned
> change has overlooked inconsistencies with the types
On Wed, 2 Aug 2023 19:15:24 GMT, Matias Saavedra Silva
wrote:
> The recent change in
> [JDK-8301996](https://bugs.openjdk.org/browse/JDK-8301996) added more
> -Wconversion warnings that are addressed in this patch. The aforementioned
> change has overlooked inconsistencies with the types
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, 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, 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 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 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, 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 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 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 Wed, 8 Mar 2023 05:17:53 GMT, Vladimir Kozlov wrote:
>> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
>> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
>> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java
tions are handled that @jddarcy mentioned.
>
> Good point. We can't guarantee that all OpenJDK ports HW do the same.
>
> If CPU has corresponding instructions we need to generate a stub during VM
> startup with HW instructions and use it in all cases (or directly the same
> instructio
On Wed, 22 Feb 2023 05:21:48 GMT, Joe Darcy wrote:
>> I'm also a bit concerned that we are rushing in to "fix" this. IIUC we have
>> three mechanisms for implementing this functionality:
>>
>> 1. The interpreted Java code
>> 2. The compiled non-intrinisc sharedRuntime code
>> 3. The compiler
On Tue, 29 Nov 2022 11:49:10 GMT, Andrew Haley wrote:
>> Andrew Haley has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Unused variable
>
> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java
> line 385:
On Thu, 24 Nov 2022 14:05:41 GMT, Andrew Haley wrote:
>> JEP 429 implementation.
>
> Andrew Haley has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Unused variable
I made a few minor suggestions, but overall the HotSpot changes look good.
On Thu, 24 Nov 2022 14:05:41 GMT, Andrew Haley wrote:
>> JEP 429 implementation.
>
> Andrew Haley has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Unused variable
src/hotspot/share/prims/jvm.cpp line 1385:
> 1383: vframeStream
On Thu, 24 Nov 2022 14:05:41 GMT, Andrew Haley wrote:
>> JEP 429 implementation.
>
> Andrew Haley has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Unused variable
src/hotspot/share/classfile/javaClasses.cpp line 1731:
> 1729: }
> 1730:
>
On Thu, 24 Nov 2022 14:05:41 GMT, Andrew Haley wrote:
>> JEP 429 implementation.
>
> Andrew Haley has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Unused variable
src/hotspot/cpu/aarch64/aarch64.ad line 3635:
> 3633: }
> 3634: }
On Fri, 4 Nov 2022 09:53:39 GMT, Andrew Haley wrote:
>> src/java.base/share/classes/java/lang/Thread.java line 1610:
>>
>>> 1608: ensureMaterializedForStackWalk(bindings);
>>> 1609: task.run();
>>> 1610: Reference.reachabilityFence(bindings);
>>
>> This
On Fri, 4 Nov 2022 09:53:39 GMT, Andrew Haley wrote:
>> src/java.base/share/classes/java/lang/Thread.java line 1610:
>>
>>> 1608: ensureMaterializedForStackWalk(bindings);
>>> 1609: task.run();
>>> 1610: Reference.reachabilityFence(bindings);
>>
>> This
On Fri, 4 Nov 2022 09:53:39 GMT, Andrew Haley wrote:
>> src/java.base/share/classes/java/lang/Thread.java line 1610:
>>
>>> 1608: ensureMaterializedForStackWalk(bindings);
>>> 1609: task.run();
>>> 1610: Reference.reachabilityFence(bindings);
>>
>> This
On Wed, 2 Nov 2022 16:23:34 GMT, Andrew Haley wrote:
> JEP 429 implementation.
src/hotspot/share/prims/jvm.cpp line 1410:
> 1408: loc = 3;
> 1409: } else if (method == resolver.thread_run_method) {
> 1410: loc = 2;
This depends on how javac numbers locals, right? It seems a
On Wed, 2 Nov 2022 16:23:34 GMT, Andrew Haley wrote:
> JEP 429 implementation.
src/hotspot/share/prims/jvm.cpp line 1410:
> 1408: loc = 3;
> 1409: } else if (method == resolver.thread_run_method) {
> 1410: loc = 2;
This depends on how javac numbers locals, right? It seems a
On Wed, 2 Nov 2022 16:23:34 GMT, Andrew Haley wrote:
> JEP 429 implementation.
src/hotspot/share/prims/jvm.cpp line 1410:
> 1408: loc = 3;
> 1409: } else if (method == resolver.thread_run_method) {
> 1410: loc = 2;
This depends on how javac numbers locals, right? It seems a
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 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 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 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
1 - 100 of 317 matches
Mail list logo
