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 the
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 the
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 the
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 fa
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 the
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 the
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 o
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
>
> src/h
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 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.
>> Doesn't
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, 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]
>CompiledMet
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 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 DeoptimizationContext::deopt_co
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 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 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:
>>> assert(extract_enqueued_deoptimization_method(_enqueued_deoptimiza
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 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 field_offs
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 field_offs
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 field_offs
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 field_offs
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 field_offs
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 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 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 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 c
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 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 c
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
> there
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
> there
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 JavaT
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 l
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 not
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.
src/hotspot/share/oops/array
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.
src/hotspot/share/oops/insta
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 ha
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)
> implem
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 f
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 f
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 f
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 f
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 f
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 f
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 f
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 _native_basic_lock_sp_
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 unl
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: assert
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 t
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 t
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 t
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 f
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 CodeCach
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 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 i
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 Ho
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
> approa
On Tue, 23 Jan 2024 13:04:43 GMT, SendaoYan wrote:
>> 8323640: [TESTBUG]testMemoryFailCount in
>> jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail
>> because OOM killed
>
> SendaoYan has updated the pull request incrementally with one additional
> commit since the last rev
On Wed, 14 Aug 2024 19:34:26 GMT, Leonid Mesnik wrote:
> The summary of the problem. Test is intermittently failing because can't get
> expected field watch event.
> The test is failing to get event in the 'setfmodw001b' thread with Xcomp only.
> I verified that frame with the method 'run' of se
cpp line 358:
>
>> 356: #endif
>> 357:
>> 358: CompilationPolicy::compile_if_required(method, CHECK);
>
> I'd like to understand what is going to happen at the line 358. Are we going
> to compile method with -Xcomp even though the `interp_only` mode is req
On Mon, 19 Aug 2024 23:19:04 GMT, David Holmes wrote:
>> This work has been split out from JDK-8328877: [JNI] The JNI Specification
>> needs to address the limitations of integer UTF-8 String lengths
>>
>> The modified UTF-8 format used by the VM can require up to six bytes to
>> represent one
On Wed, 14 Aug 2024 19:34:26 GMT, Leonid Mesnik wrote:
> The summary of the problem. Test is intermittently failing because can't get
> expected field watch event.
> The test is failing to get event in the 'setfmodw001b' thread with Xcomp only.
> I verified that frame with the method 'run' of se
On Tue, 20 Aug 2024 17:38:01 GMT, Leonid Mesnik wrote:
>> The summary of the problem. Test is intermittently failing because can't get
>> expected field watch event.
>> The test is failing to get event in the 'setfmodw001b' thread with Xcomp
>> only.
>> I verified that frame with the method 'ru
On Tue, 20 Aug 2024 04:09:04 GMT, David Holmes wrote:
>> This work has been split out from JDK-8328877: [JNI] The JNI Specification
>> needs to address the limitations of integer UTF-8 String lengths
>>
>> The modified UTF-8 format used by the VM can require up to six bytes to
>> represent one
On Tue, 20 Aug 2024 04:09:04 GMT, David Holmes wrote:
>> This work has been split out from JDK-8328877: [JNI] The JNI Specification
>> needs to address the limitations of integer UTF-8 String lengths
>>
>> The modified UTF-8 format used by the VM can require up to six bytes to
>> represent one
On Tue, 20 Aug 2024 04:09:04 GMT, David Holmes wrote:
>> This work has been split out from JDK-8328877: [JNI] The JNI Specification
>> needs to address the limitations of integer UTF-8 String lengths
>>
>> The modified UTF-8 format used by the VM can require up to six bytes to
>> represent one
On Tue, 20 Aug 2024 04:09:04 GMT, David Holmes wrote:
>> This work has been split out from JDK-8328877: [JNI] The JNI Specification
>> needs to address the limitations of integer UTF-8 String lengths
>>
>> The modified UTF-8 format used by the VM can require up to six bytes to
>> represent one
On Tue, 20 Aug 2024 04:09:04 GMT, David Holmes wrote:
>> This work has been split out from JDK-8328877: [JNI] The JNI Specification
>> needs to address the limitations of integer UTF-8 String lengths
>>
>> The modified UTF-8 format used by the VM can require up to six bytes to
>> represent one
On Tue, 27 Aug 2024 07:07:11 GMT, David Holmes wrote:
>> src/hotspot/share/classfile/javaClasses.cpp line 307:
>>
>>> 305: {
>>> 306: ResourceMark rm;
>>> 307: size_t utf8_len = static_cast(length);
>>
>> I think there should be an assert that length is not negative, probably at
>> t
On Tue, 27 Aug 2024 07:09:33 GMT, David Holmes wrote:
>> src/hotspot/share/classfile/javaClasses.cpp line 555:
>>
>>> 553: bool is_latin1 = java_lang_String::is_latin1(java_string);
>>> 554:
>>> 555: if (length == 0) return nullptr;
>>
>> Should this be checking for length <= 0? It l
On Tue, 27 Aug 2024 07:20:27 GMT, David Holmes wrote:
>> src/hotspot/share/classfile/javaClasses.cpp line 588:
>>
>>> 586: size_t utf8_len = static_cast(length);
>>> 587: const char* base = UNICODE::as_utf8(position, utf8_len);
>>> 588: Symbol* sym = SymbolTable::new_symbol(base,
>>
On Tue, 27 Aug 2024 07:23:14 GMT, David Holmes wrote:
>> src/hotspot/share/classfile/javaClasses.cpp line 633:
>>
>>> 631: }
>>> 632:
>>> 633: int java_lang_String::utf8_length_as_int(oop java_string, typeArrayOop
>>> value) {
>>
>> Why not call java_lang_String::utf8_length() here instead of
On Tue, 20 Aug 2024 04:09:04 GMT, David Holmes wrote:
>> This work has been split out from JDK-8328877: [JNI] The JNI Specification
>> needs to address the limitations of integer UTF-8 String lengths
>>
>> The modified UTF-8 format used by the VM can require up to six bytes to
>> represent one
On Tue, 27 Aug 2024 12:10:36 GMT, David Holmes wrote:
>> src/hotspot/share/utilities/utf8.cpp line 127:
>>
>>> 125: prev = c;
>>> 126: }
>>> 127: return checked_cast(num_chars);
>>
>> Ideally, this function would return size_t.
>
> Why? I think that would have a large flow on effect. An
On Tue, 27 Aug 2024 21:21:01 GMT, David Holmes wrote:
> If you try to accommodate arbitrary future use then every method in the VM
> would need to enforce every single precondition and invariant it expects
> "just in case" and that is not practical.
I'm basically arguing for Functional Testing
On Tue, 20 Aug 2024 04:09:04 GMT, David Holmes wrote:
>> This work has been split out from JDK-8328877: [JNI] The JNI Specification
>> needs to address the limitations of integer UTF-8 String lengths
>>
>> The modified UTF-8 format used by the VM can require up to six bytes to
>> represent one
On Wed, 28 Aug 2024 01:24:43 GMT, David Holmes wrote:
>>> If you try to accommodate arbitrary future use then every method in the VM
>>> would need to enforce every single precondition and invariant it expects
>>> "just in case" and that is not practical.
>>
>> I'm basically arguing for Functi
On Thu, 29 Aug 2024 18:50:42 GMT, Coleen Phillimore wrote:
>> Move JVM implementation access flags that are not specified by the classfile
>> format into Klass so we can shrink AccessFlags to u2 in a future change.
>>
>> Tested with tier1-7.
>>
>> NOTE: there are arm, ppc and s390 changes to t
On Thu, 29 Aug 2024 18:50:42 GMT, Coleen Phillimore wrote:
>> Move JVM implementation access flags that are not specified by the classfile
>> format into Klass so we can shrink AccessFlags to u2 in a future change.
>>
>> Tested with tier1-7.
>>
>> NOTE: there are arm, ppc and s390 changes to t
On Thu, 29 Aug 2024 18:50:42 GMT, Coleen Phillimore wrote:
>> Move JVM implementation access flags that are not specified by the classfile
>> format into Klass so we can shrink AccessFlags to u2 in a future change.
>>
>> Tested with tier1-7.
>>
>> NOTE: there are arm, ppc and s390 changes to t
On Thu, 29 Aug 2024 18:50:42 GMT, Coleen Phillimore wrote:
>> Move JVM implementation access flags that are not specified by the classfile
>> format into Klass so we can shrink AccessFlags to u2 in a future change.
>>
>> Tested with tier1-7.
>>
>> NOTE: there are arm, ppc and s390 changes to t
On Thu, 29 Aug 2024 22:29:43 GMT, Dean Long wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add in graal flags and a comment.
>
> src/hotspot/share/ci/c
On Thu, 29 Aug 2024 18:50:42 GMT, Coleen Phillimore wrote:
>> Move JVM implementation access flags that are not specified by the classfile
>> format into Klass so we can shrink AccessFlags to u2 in a future change.
>>
>> Tested with tier1-7.
>>
>> NOTE: there are arm, ppc and s390 changes to t
On Thu, 29 Aug 2024 18:50:42 GMT, Coleen Phillimore wrote:
>> Move JVM implementation access flags that are not specified by the classfile
>> format into Klass so we can shrink AccessFlags to u2 in a future change.
>>
>> Tested with tier1-7.
>>
>> NOTE: there are arm, ppc and s390 changes to t
On Fri, 30 Aug 2024 14:00:44 GMT, Coleen Phillimore wrote:
>> Move JVM implementation access flags that are not specified by the classfile
>> format into Klass so we can shrink AccessFlags to u2 in a future change.
>>
>> Tested with tier1-7.
>>
>> NOTE: there are arm, ppc and s390 changes to t
On Fri, 30 Aug 2024 21:35:49 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/opto/library_call.cpp line 3777:
>>
>>> 3775: Node* p = basic_plus_adr(kls, in_bytes(Klass::misc_flags_offset()));
>>> 3776: Node* mods = make_load(nullptr, p, TypeInt::UBYTE, T_BOOLEAN,
>>> MemNode::unordered);
On Fri, 30 Aug 2024 21:51:49 GMT, Coleen Phillimore wrote:
>> Move JVM implementation access flags that are not specified by the classfile
>> format into Klass so we can shrink AccessFlags to u2 in a future change.
>>
>> Tested with tier1-7.
>>
>> NOTE: there are arm, ppc and s390 changes to t
On Fri, 6 Sep 2024 13:12:29 GMT, Coleen Phillimore wrote:
>> This patch cleans up the use of `get_new_method()` so callers don't have to
>> worry about throwing `NoSuchMethodError`. The method is refactored to throw
>> the error and avoid ever returning nullptr. Verified with tier1-5 tests.
>
>
On Fri, 6 Sep 2024 12:51:38 GMT, Coleen Phillimore wrote:
> We do the same thing with illegal_access_error() where the arguments may not
> match and there's a special case for this and no_such_method_error() in
> dependencies. Are the compilers confused by this too?
If the compiler used the va
On Tue, 10 Sep 2024 06:50:13 GMT, David Holmes wrote:
>> So that implies that you trust my reading of this code. It is complicated
>> enough that testing both seems like a safe thing to do and somewhat
>> clarifying, or else adding an assert like:
>>
>> assert(new_method != nullptr || old
On Wed, 11 Sep 2024 21:02:41 GMT, Matias Saavedra Silva
wrote:
>> This patch cleans up the use of `get_new_method()` so callers don't have to
>> worry about throwing `NoSuchMethodError`. The method is refactored to throw
>> the error and avoid ever returning nullptr. Verified with tier1-5 test
On Wed, 11 Sep 2024 21:02:41 GMT, Matias Saavedra Silva
wrote:
>> This patch cleans up the use of `get_new_method()` so callers don't have to
>> worry about throwing `NoSuchMethodError`. The method is refactored to throw
>> the error and avoid ever returning nullptr. Verified with tier1-5 test
1 - 100 of 210 matches
Mail list logo
