On Wed, 24 Sep 2025 11:44:58 GMT, Fredrik Bredberg
wrote:
>> src/hotspot/share/runtime/vmStructs.cpp line 685:
>>
>>> 683: volatile_nonstatic_field(ObjectMonitor, _owner,
>>>int64_t) \
>>> 684: volatile_nonstatic_fi
On Tue, 23 Sep 2025 09:29:57 GMT, Fredrik Bredberg
wrote:
> This is a general cleanup after removing `LockingMode` related code.
> It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261).
> It includes:
> - Removing asserts that are no longer necessary, since we removed leg
On Tue, 9 Sep 2025 22:09:06 GMT, Ioi Lam wrote:
>> The purpose of this PR is to simplify JNI code and also to avoid unnecessary
>> `InstanceKlass::cast()` calls.
>>
>> This PR is intended to be a strict clean-up that preserves existing
>> behaviors.
>>
>> The following helper functions are ad
On Sat, 20 Sep 2025 06:43:00 GMT, Ioi Lam wrote:
>> Simplify the boilerplate code in jvm.cpp that calls
>> `JvmtiThreadState::class_to_verify_considering_redefinition()`, and reduce
>> the number of `InstanceKlass::cast()` calls.
>>
>> I also changed a few fields/arguments from `Klass*` to `In
On Thu, 18 Sep 2025 07:41:31 GMT, Johan Sjölen wrote:
>> Hi,
>>
>> This is a refactoring of the way that we store the Bootstrap method
>> attribute in the ConstantPool class. We used to have a single `Array`
>> which was divided into a section of `u4` offsets and a section which was the
>> ac
On Fri, 19 Sep 2025 03:06:42 GMT, Ioi Lam wrote:
>> Simplify the boilerplate code in jvm.cpp that calls
>> `JvmtiThreadState::class_to_verify_considering_redefinition()`, and reduce
>> the number of `InstanceKlass::cast()` calls.
>>
>> I also changed a few fields/arguments from `Klass*` to `In
On Tue, 16 Sep 2025 02:44:26 GMT, Ioi Lam wrote:
> Simplify the boilerplate code in jvm.cpp that calls
> `JvmtiThreadState::class_to_verify_considering_redefinition()`, and reduce
> the number of `InstanceKlass::cast()` calls.
>
> I also changed a few fields/arguments from `Klass*` to `Instanc
On Thu, 11 Sep 2025 08:35:05 GMT, Paul Hübner wrote:
> Hi all,
>
> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop`
> in `jdk.internal.reflect.ConstantPool`. This PR:
> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder`
> (name to be consisten
On Thu, 11 Sep 2025 08:35:05 GMT, Paul Hübner wrote:
> Hi all,
>
> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop`
> in `jdk.internal.reflect.ConstantPool`. This PR:
> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder`
> (name to be consisten
On Wed, 10 Sep 2025 22:46:00 GMT, Ioi Lam wrote:
>> The purpose of this PR is to simplify JNI code and also to avoid unnecessary
>> `InstanceKlass::cast()` calls by adding a new function:
>>
>>
>> static InstanceKlass* java_lang_Class::as_InstanceKlass(oop java_class);
>>
>>
>> This PR is i
On Wed, 10 Sep 2025 09:39:28 GMT, Stefan Karlsson wrote:
>> There are 54 cases where we call as_Klass(JNIHandles::resolve_non_null(x)),
>> so I think it would be nice to have a way to write less code.
> I think you should deal with that by adding a helper function inside jni.cpp
> instead of e
On Fri, 5 Sep 2025 19:15:33 GMT, Evgeny Astigeevich
wrote:
>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and
>> `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be
>> rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not
On Thu, 4 Sep 2025 09:55:23 GMT, Fredrik Bredberg wrote:
>> src/hotspot/share/runtime/synchronizer.inline.hpp line 48:
>>
>>> 46: assert(current == Thread::current(), "must be");
>>> 47:
>>> 48: LightweightSynchronizer::enter(obj, lock, current);
>>
>> In the further RFE, we should remov
On Thu, 4 Sep 2025 12:07:43 GMT, Fredrik Bredberg wrote:
>> Since the integration of
>> [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode`
>> flag can no longer be set by the user. After that, a number of PRs has been
>> integrated which has removed all `LockingMode`
On Thu, 4 Sep 2025 10:18:27 GMT, Fredrik Bredberg wrote:
>> src/hotspot/share/runtime/basicLock.hpp line 53:
>>
>>> 51: static int displaced_header_offset_in_bytes() { return
>>> metadata_offset_in_bytes(); }
>>> 52:
>>> 53: // For lightweight locking
>>
>> If the following are for lightw
On Thu, 4 Sep 2025 02:26:26 GMT, David Holmes wrote:
>> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 769:
>>
>>> 767:
>>> 768: // LightweightSynchronizer::inflate_locked_or_imse is used to to get
>>> an inflated
>>> 769: // ObjectMonitor* when lightweight locking is used. It is u
On Tue, 2 Sep 2025 21:08:25 GMT, Ioi Lam wrote:
>> By adding an `InstanceKlass* InstanceKlass::super()` method to shadow
>> `Klass* Klass:super()`, this PR makes it possible to simplify the following
>> code
>>
>>
>> InstanceKlass* ik;
>> InstanceKlass* s;
>> s = InstanceKlass::cast(ik->super
On Tue, 2 Sep 2025 21:45:03 GMT, Evgeny Astigeevich
wrote:
>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and
>> `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be
>> rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not
On Fri, 29 Aug 2025 22:48:06 GMT, Evgeny Astigeevich
wrote:
>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and
>> `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be
>> rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not
On Tue, 2 Sep 2025 04:59:09 GMT, David Holmes wrote:
>> By adding an `InstanceKlass* InstanceKlass::super()` method to shadow
>> `Klass* Klass:super()`, this PR makes it possible to simplify the following
>> code
>>
>>
>> InstanceKlass* ik;
>> InstanceKlass* s;
>> s = InstanceKlass::cast(ik->
On Tue, 2 Sep 2025 08:24:10 GMT, Fredrik Bredberg wrote:
> Since the integration of
> [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode`
> flag can no longer be set by the user. After that, a number of PRs has been
> integrated which has removed all `LockingMode` rela
On Tue, 2 Sep 2025 11:43:01 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/oops/instanceKlass.hpp line 924:
>>
>>> 922: // always an InstanceKlass (or nullptr)
>>> 923: InstanceKlass* super() const {
>>> 924: return (Klass::super() == nullpt
On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich
wrote:
>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and
>> `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be
>> rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not
On Wed, 27 Aug 2025 06:37:44 GMT, David Holmes wrote:
>> (I realize this is a tangent, but maybe there is a separate bug here...)
>>
>>> To have a Class object it must have already undergone the "preparation"
>>> part of linking (it is done at the end of loading when we create the class
>>> mi
On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich
wrote:
>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and
>> `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be
>> rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not
On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich
wrote:
>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and
>> `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be
>> rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not
On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich
wrote:
>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and
>> `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be
>> rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not
On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich
wrote:
>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and
>> `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be
>> rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not
On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich
wrote:
>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and
>> `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be
>> rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not
On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich
wrote:
>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and
>> `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be
>> rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not
On Fri, 11 Jul 2025 05:44:08 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4053:
>>
>>> 4051: }
>>> 4052:
>>> 4053: void VM_RedefineClasses::compute_matching_methods() {
>>
>> I can't see that this method actually still does anything useful. ??
>
> I thin
On Fri, 11 Jul 2025 05:49:40 GMT, Serguei Spitsyn wrote:
>> The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as
>> a temporary backward compatibility flag under JDK-8192936 and was
>> immediately marked as Deprecate. The fix is to obsolete this option in JDK
>> 26 and
On Thu, 3 Jul 2025 17:10:03 GMT, Calvin Cheung wrote:
> It looks good to me. I like this simplification. But I'm curious what was the
> original reason to have the classLoaderExt?
I think it was from before we settled on the Shared suffix for CDS methods.
-
PR Comment: https://git
On Thu, 3 Jul 2025 17:12:55 GMT, Calvin Cheung wrote:
>> After the refactoring work done via
>> [JDK-8280682](https://bugs.openjdk.org/browse/JDK-8280682), there are only
>> three functions remaining in the ClassLoaderExt class. This RFE is to move
>> those remaining functions into other class
On Thu, 3 Jul 2025 05:16:54 GMT, Calvin Cheung wrote:
> After the refactoring work done via
> [JDK-8280682](https://bugs.openjdk.org/browse/JDK-8280682), there are only
> three functions remaining in the ClassLoaderExt class. This RFE is to move
> those remaining functions into other classes s
On Wed, 2 Jul 2025 18:14:57 GMT, Ioi Lam wrote:
>> A module has both a Java and a C++ representation
>>
>> - C++: `ModuleEntry`
>> - Java: `java.lang.Module`
>>
>> In C++, we have the following two methods
>>
>> - `ModuleEntry* InstanceKlass::module()`
>> - `oop ModuleEntry::module()`
>>
>> T
On Wed, 2 Jul 2025 17:33:40 GMT, Ioi Lam wrote:
> A module has both a Java and a C++ representation
>
> - C++: `ModuleEntry`
> - Java: `java.lang.Module`
>
> In C++, we have the following two methods
>
> - `ModuleEntry* InstanceKlass::module()`
> - `oop ModuleEntry::module()`
>
> This can lea
On Tue, 17 Jun 2025 17:11:01 GMT, Coleen Phillimore wrote:
> I copied this code for another test in the Valhalla repo and thought it would
> be a good utility function. It might be better written using the Classfile
> API.
> Tested with test.
This pull request has now bee
On Tue, 1 Jul 2025 01:55:48 GMT, Coleen Phillimore wrote:
>> I copied this code for another test in the Valhalla repo and thought it
>> would be a good utility function. It might be better written using the
>> Classfile API.
>> Tested with test.
>
> Coleen P
is not reproduced anymore with corresponding test
>> after the fix.
>>
>> Many thanks to Coleen for detailed explanation of class redefinition.
>
> Leonid Mesnik has updated the pull request incrementally with two additional
> commits since the last revision:
>
On Tue, 1 Jul 2025 03:17:41 GMT, Leonid Mesnik wrote:
>> The segv/eav happens in the case if JvmtiBreakpoint::_method's class
>> redefined old between getting the Method* from jmethodid in the
>> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) {..} and
>> and actual setting breakpo
On Tue, 1 Jul 2025 09:39:22 GMT, Anton Artemov wrote:
>> Hi, please consider the following changes:
>>
>> There are many classes inherited from the `HandshakeClosure` class, but they
>> do not follow the same naming convention. In this PR we address this issue,
>> all names are normalized in t
On Mon, 30 Jun 2025 23:26:17 GMT, Leonid Mesnik wrote:
>> Coleen Phillimore has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Update test/lib/RedefineClassHelper.java
>>
>>Co-authored-by
> I copied this code for another test in the Valhalla repo and thought it would
> be a good utility function. It might be better written using the Classfile
> API.
> Tested with test.
Coleen Phillimore has updated the pull request incrementally with one
additional commit si
On Mon, 30 Jun 2025 11:38:23 GMT, Coleen Phillimore wrote:
>> I copied this code for another test in the Valhalla repo and thought it
>> would be a good utility function. It might be better written using the
>> Classfile API.
>> Tested with test.
>
> Coleen P
> I copied this code for another test in the Valhalla repo and thought it would
> be a good utility function. It might be better written using the Classfile
> API.
> Tested with test.
Coleen Phillimore has updated the pull request incrementally with three
additional commits si
On Mon, 30 Jun 2025 11:53:36 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/prims/jvmtiImpl.cpp line 188:
>>
>>> 186:
>>> 187: void VM_ChangeBreakpoints::doit() {
>>> 188: if (_bp->method() != Method::resolve_jmethod_id(_preservred_method)) {
On Mon, 30 Jun 2025 04:38:41 GMT, David Holmes wrote:
>> The segv/eav happens in the case if JvmtiBreakpoint::_method's class
>> redefined old between getting the Method* from jmethodid in the
>> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) {..} and
>> and actual setting breakpo
> I copied this code for another test in the Valhalla repo and thought it would
> be a good utility function. It might be better written using the Classfile
> API.
> Tested with test.
Coleen Phillimore has updated the pull request incrementally with one
additional commit si
On Mon, 30 Jun 2025 05:22:11 GMT, David Holmes wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Rename replaceAllStrings to replaceClassName and add back the byte buffer
>> ver
> I copied this code for another test in the Valhalla repo and thought it would
> be a good utility function. It might be better written using the Classfile
> API.
> Tested with test.
Coleen Phillimore has updated the pull request incrementally with two
additional commits si
On Fri, 27 Jun 2025 09:10:26 GMT, Anton Artemov wrote:
> Hi, please consider the following changes:
>
> There are many classes inherited from the `HandshakeClosure` class, but they
> do not follow the same naming convention. In this PR we address this issue,
> all names are normalized in the f
On Fri, 27 Jun 2025 04:21:01 GMT, David Holmes wrote:
>>> the lambda just copies everything over as-is.
>> ..
>>> But be aware this code does not change the class name use anywhere in the
>>> code, descriptors, handles, annotation, etc..., just the class name itself.
>>
>> @coleenp don't we nee
On Thu, 26 Jun 2025 05:03:14 GMT, Leonid Mesnik wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Made it even shorter.
>
> test/lib/RedefineClassHelper.
On Thu, 26 Jun 2025 11:58:11 GMT, Coleen Phillimore wrote:
>> I copied this code for another test in the Valhalla repo and thought it
>> would be a good utility function. It might be better written using the
>> Classfile API.
>> Tested with test.
>
> Coleen P
> I copied this code for another test in the Valhalla repo and thought it would
> be a good utility function. It might be better written using the Classfile
> API.
> Tested with test.
Coleen Phillimore has updated the pull request incrementally with one
additional commit si
On Fri, 16 May 2025 12:18:42 GMT, Coleen Phillimore wrote:
> This change uses a ConcurrentHashTable to associate Method* with jmethodID,
> instead of an indirection. JNI is deprecated in favor of using Panama to
> call methods, so I don't think we're concerned about JN
On Thu, 26 Jun 2025 18:01:58 GMT, Coleen Phillimore wrote:
>> This change uses a ConcurrentHashTable to associate Method* with jmethodID,
>> instead of an indirection. JNI is deprecated in favor of using Panama to
>> call methods, so I don't think we're concerned
On Thu, 26 Jun 2025 11:53:43 GMT, Coleen Phillimore wrote:
>> test/lib/RedefineClassHelper.java line 29:
>>
>>> 27: import java.lang.classfile.ClassFile;
>>> 28: import java.lang.classfile.ClassModel;
>>> 29: import java.util.Map;
>>
>> N
On Thu, 26 Jun 2025 16:47:35 GMT, Adam Sotona wrote:
>>> Seriously though, which part of that is doing the actual replace??
>>
>> `ClassDesc.of(newClassName)` defines a new class with the new name, and the
>> lambda just copies everything over as-is.
>
> It can be also written as:
> `return Cla
On Thu, 26 Jun 2025 16:35:26 GMT, Daniel D. Daugherty
wrote:
>> ugh that makes the line too long for me.
>
> How about just: s/locks/can also lock/
Done - that's not too wide for my screen.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2169688031
On Thu, 26 Jun 2025 12:20:57 GMT, Coleen Phillimore wrote:
>> This change uses a ConcurrentHashTable to associate Method* with jmethodID,
>> instead of an indirection. JNI is deprecated in favor of using Panama to
>> call methods, so I don't think we're concerned
mechanism increases the
> method_idnum to do this. In the future maybe we could throw
> NoSuchMethodError if you try to create a jmethodID out of an obsolete method
> and remove all this code. But that's not in this change.
>
> Tested with tier1-4, 5-7.
Coleen Phillimore
mechanism increases the
> method_idnum to do this. In the future maybe we could throw
> NoSuchMethodError if you try to create a jmethodID out of an obsolete method
> and remove all this code. But that's not in this change.
>
> Tested with tier1-4, 5-7.
Coleen Phillimore has
On Wed, 25 Jun 2025 17:48:02 GMT, Daniel D. Daugherty
wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix the test
>
> src/hotspot/share/runtime/mutexLocker.cpp lin
> I copied this code for another test in the Valhalla repo and thought it would
> be a good utility function. It might be better written using the Classfile
> API.
> Tested with test.
Coleen Phillimore has updated the pull request incrementally with two
additional commits si
On Thu, 26 Jun 2025 07:30:13 GMT, David Holmes wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Made it even shorter.
>
> test/lib/RedefineClassHelper.
> I copied this code for another test in the Valhalla repo and thought it would
> be a good utility function. It might be better written using the Classfile
> API.
> Tested with test.
Coleen Phillimore has updated the pull request incrementally with one
additional commit si
On Wed, 25 Jun 2025 18:50:11 GMT, Chen Liang wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use ClassFile API to replace the class name.
>
> test/lib/RedefineClas
> I copied this code for another test in the Valhalla repo and thought it would
> be a good utility function. It might be better written using the Classfile
> API.
> Tested with test.
Coleen Phillimore has updated the pull request incrementally with one
additional commit si
On Wed, 25 Jun 2025 05:30:18 GMT, Serguei Spitsyn wrote:
>> `jdk.internal.classfile.components` has a `ClassRemapper` that may serve
>> this purpose. It updates all internal names and occurrences in descriptors.
>
> BTW, I've also noticed this issue with returning 0 but forgot to post my
> ques
> I copied this code for another test in the Valhalla repo and thought it would
> be a good utility function. It might be better written using the Classfile
> API.
> Tested with test.
Coleen Phillimore has updated the pull request incrementally with one
additional commit si
On Fri, 20 Jun 2025 20:41:21 GMT, Coleen Phillimore wrote:
>> This change uses a ConcurrentHashTable to associate Method* with jmethodID,
>> instead of an indirection. JNI is deprecated in favor of using Panama to
>> call methods, so I don't think we're concerned
On Mon, 23 Jun 2025 21:18:09 GMT, Alex Menkov wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add a byte buffer version and rename parameters.
>
> test/lib/RedefineClas
On Wed, 18 Jun 2025 14:44:54 GMT, Coleen Phillimore wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repos
On Wed, 25 Jun 2025 11:26:22 GMT, Anton Artemov wrote:
>> This PR contains changes for the 1st phase of the `LockingMode` flag
>> obsoletion.
>>
>> The work is done by @fbredber, I have taken it over and am finishing it
>> while he's on vacation.
>>
>> In the 1st phase one keeps the `Lockin
On Tue, 24 Jun 2025 09:12:00 GMT, Anton Artemov wrote:
>> test/jtreg-ext/requires/VMProps.java line 424:
>>
>>> 422: * Note: Lightweight locking does not support RTM (for now).
>>> 423: */
>>> 424: protected String vmRTMCompiler() {
>>
>> [JDK-8358542](https://bugs.openjdk.org/bro
On Wed, 18 Jun 2025 14:44:54 GMT, Coleen Phillimore wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repos
On Fri, 20 Jun 2025 20:41:21 GMT, Coleen Phillimore wrote:
>> This change uses a ConcurrentHashTable to associate Method* with jmethodID,
>> instead of an indirection. JNI is deprecated in favor of using Panama to
>> call methods, so I don't think we're concerned
On Wed, 18 Jun 2025 14:44:54 GMT, Coleen Phillimore wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repos
On Wed, 18 Jun 2025 14:44:54 GMT, Coleen Phillimore wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repos
On Fri, 20 Jun 2025 20:41:21 GMT, Coleen Phillimore wrote:
>> This change uses a ConcurrentHashTable to associate Method* with jmethodID,
>> instead of an indirection. JNI is deprecated in favor of using Panama to
>> call methods, so I don't think we're concerned
On Wed, 18 Jun 2025 14:44:54 GMT, Coleen Phillimore wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repos
On Wed, 18 Jun 2025 12:13:38 GMT, Coleen Phillimore wrote:
> This uses names for frame types for stackmaps in the verifier and
> redefinition.
> Tested with tier1-7.
This pull request has now been integrated.
Changeset: 28e96e33
Author: Coleen Phillimore
URL:
On Mon, 23 Jun 2025 12:06:03 GMT, Coleen Phillimore wrote:
>> This uses names for frame types for stackmaps in the verifier and
>> redefinition.
>> Tested with tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with three
> additional comm
On Mon, 23 Jun 2025 15:47:40 GMT, Leonid Mesnik wrote:
>> getBytecodes propagates the exception from getResourceAsStream. If I catch
>> IOException (?), what should it do?
>
> I didn't thought about this, but I think that's ok. I just propose to closed
> stream, not changing the exception hand
On Mon, 23 Jun 2025 20:45:13 GMT, Leonid Mesnik wrote:
>> Oh so this try is a try-with-resources and it'll close the stream? It
>> compiles without a catch clause.
>
> yes, only change is that stream is closed.
That's really cool. Thanks for the suggestion.
-
PR Review Comment:
> I copied this code for another test in the Valhalla repo and thought it would
> be a good utility function. It might be better written using the Classfile
> API.
> Tested with test.
Coleen Phillimore has updated the pull request incrementally with one
additional commit si
On Wed, 18 Jun 2025 07:52:02 GMT, David Holmes wrote:
>> This PR contains changes for the 1st phase of the `LockingMode` flag
>> obsoletion.
>>
>> The work is done by @fbredber, I have taken it over and am finishing it
>> while he's on vacation.
>>
>> In the 1st phase one keeps the `Locking
On Tue, 17 Jun 2025 08:39:49 GMT, Anton Artemov wrote:
> This PR contains changes for the 1st phase of the `LockingMode` flag
> obsoletion.
>
> The work is done by @fbredber, I have taken it over and am finishing it while
> he's on vacation.
>
> In the 1st phase one keeps the `LockingMode`
On Fri, 20 Jun 2025 21:35:33 GMT, Leonid Mesnik wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add a byte buffer version and rename parameters.
>
> test/lib/RedefineClassHelper.
On Fri, 20 Jun 2025 20:41:21 GMT, Coleen Phillimore wrote:
>> This change uses a ConcurrentHashTable to associate Method* with jmethodID,
>> instead of an indirection. JNI is deprecated in favor of using Panama to
>> call methods, so I don't think we're concerned
On Mon, 23 Jun 2025 12:02:43 GMT, Coleen Phillimore wrote:
>> This uses names for frame types for stackmaps in the verifier and
>> redefinition.
>> Tested with tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with three
> additional comm
> This uses names for frame types for stackmaps in the verifier and
> redefinition.
> Tested with tier1-7.
Coleen Phillimore has updated the pull request incrementally with three
additional commits since the last revision:
- Update src/hotspot/share/prims/jvmtiRedefineClasses.cpp
On Thu, 19 Jun 2025 10:02:45 GMT, Aleksey Shipilev wrote:
>> Thank you for the backport! @shipilev indicated that the backport to 21
>> should wait a bit, could you clarify when should I file that (e.g. end of
>> July, ...)?
>
>> @shipilev indicated that the backport to 21 should wait a bit, co
On Thu, 19 Jun 2025 06:33:08 GMT, Thomas Stuefe wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add a basic gtest.
>
> I feel apprehensive about this; the solution feels pretty
On Thu, 19 Jun 2025 00:45:30 GMT, David Holmes wrote:
> This still seems racy though. What if the lookup succeeds but at the same
> time the class is to be unloaded?
Yes, It won't be at the same time, since lookup and remove_jmethod_ids hold the
JmethodIdCreation_lock. But this is a good ques
mechanism increases the
> method_idnum to do this. In the future maybe we could throw
> NoSuchMethodError if you try to create a jmethodID out of an obsolete method
> and remove all this code. But that's not in this change.
>
> Tested with tier1-4, 5-7.
Coleen Phillimore has
On Fri, 20 Jun 2025 15:05:03 GMT, Coleen Phillimore wrote:
>> This uses names for frame types for stackmaps in the verifier and
>> redefinition.
>> Tested with tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with one
> additional com
On Thu, 19 Jun 2025 00:07:49 GMT, David Holmes wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add a basic gtest.
>
> src/hotspot/share/oops/instanceKlass.cpp line 2395:
>
&
1 - 100 of 935 matches
Mail list logo
