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
> 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 breakpoint in the VM operation VM_ChangeBreakpoints.
>
> Here are
On Mon, 30 Jun 2025 13:03:23 GMT, Artem Semenov wrote:
>> The defect has been detected and confirmed in the function
>> ```IterateOverHeapObjectClosure::do_object()``` located in the file
>> ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis.
>> This defect can potentially
On Mon, 30 Jun 2025 11:24:28 GMT, Kevin Walls wrote:
>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native
>> VM JavaThread from a java.lang.Thread. This is hard to reproduce but a
>> thread that has since terminated can provoke a crash. Recognise this and
>> return a
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 Phillimore has updated the pull reque
On Mon, 30 Jun 2025 21:20:55 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 breakp
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: David Holmes
>> <62092539+dholmes-...@
> 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 since the last revisio
On Thu, 19 Jun 2025 00:33:42 GMT, Chris Plummer wrote:
>> [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117) removed support
>> for non-local debuggees, so now only local debuggees are supported. However,
>> there are now a lot of references to the "local" debuggee mode which are not
>
On Mon, 30 Jun 2025 13:03:23 GMT, Artem Semenov wrote:
>> The defect has been detected and confirmed in the function
>> ```IterateOverHeapObjectClosure::do_object()``` located in the file
>> ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis.
>> This defect can potentially
On Mon, 30 Jun 2025 13:03:23 GMT, Artem Semenov wrote:
>> The defect has been detected and confirmed in the function
>> ```IterateOverHeapObjectClosure::do_object()``` located in the file
>> ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis.
>> This defect can potentially
On Mon, 30 Jun 2025 16:49:02 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 Phillimore has updated the pull requ
On Mon, 23 Jun 2025 17:15:29 GMT, Chris Plummer wrote:
>> test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java line 50:
>>
>>> 48: * @see nsk.share.jdwp.Debugee
>>> 49: */
>>> 50: public class DebugeeProcess {
>>
>> Are there any reason to make it non-abstract.. Even DebugeeProces
On Thu, 19 Jun 2025 00:33:42 GMT, Chris Plummer wrote:
>> [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117) removed support
>> for non-local debuggees, so now only local debuggees are supported. However,
>> there are now a lot of references to the "local" debuggee mode which are not
>
On Sat, 28 Jun 2025 05:02:56 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 breakpoint
> 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 breakpoint in the VM operation VM_ChangeBreakpoints.
>
> Here are
On Mon, 30 Jun 2025 20:47:35 GMT, Serguei Spitsyn wrote:
> The issue itself is kind of artificial. The debugger should not set
> breakpoints concurrently with class redefinitions. But suppose this can
> really happen. Then I have a little preference to fix this by setting a
> breakpoint after
On Sat, 28 Jun 2025 05:02:56 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 breakpoint
On Mon, 30 Jun 2025 05:53:59 GMT, Leonid Mesnik wrote:
> I recently updated RunThese test to have more testing in this areas.
As I understand you've added some specific stressing to reliably catch issues
like this one.
-
PR Comment: https://git.openjdk.org/jdk/pull/26031#issuecomm
On Mon, 30 Jun 2025 11:24:28 GMT, Kevin Walls wrote:
>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native
>> VM JavaThread from a java.lang.Thread. This is hard to reproduce but a
>> thread that has since terminated can provoke a crash. Recognise this and
>> return a
> The classes javax.management.AttributeList, and
> javax.management.relation.RoleList and UnresolvedRoleList, have a historical
> feature where they accept objects of the wrong type, and only check for wrong
> objects when the "asList()" method is called.
>
> This feature should be removed, an
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 Phillimore has updated the pull requ
> 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 since the last revi
note that for *nix systems that use SIGQUIT as an initiator for attach,
there exists a potential fatal "bug" where (especially a programmatic)
attach attempt may send SIGQUIT before the target/attachee JVM has
initialized such that its signal handlers
are installed.
If the target JVM has not i
> The classes javax.management.AttributeList, and
> javax.management.relation.RoleList and UnresolvedRoleList, have a historical
> feature where they accept objects of the wrong type, and only check for wrong
> objects when the "asList()" method is called.
>
> This feature should be removed, an
> The defect has been detected and confirmed in the function
> ```IterateOverHeapObjectClosure::do_object()``` located in the file
> ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This
> defect can potentially lead to a null pointer dereference.
>
> The pointer ```oop
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 Phillimore has updated the pull requ
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)) {
>>
>> Suggestion:
>>
>> if (_bp->method() !=
On Fri, 27 Jun 2025 19:48:14 GMT, Daniel D. Daugherty
wrote:
>> src/hotspot/share/prims/jvmtiEnvBase.hpp line 511:
>>
>>> 509: };
>>> 510:
>>> 511: class SetForceEarlyReturnHandshakeClosure : public
>>> JvmtiUnitedHandshakeClosure {
>>
>> I do not support this unification over JVMTI files. T
> 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 following way:
>
> `XXXDummyClassNameClosure -> XXXDummyC
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 since the last revisio
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
>> version of the function.
>
> test/li
On Thu, 26 Jun 2025 08:26:44 GMT, Kevin Walls wrote:
>> Great catch Dan! I totally missed the TLH at the start of
>> `get_thread_snapshot`. I knew something was off here but couldn't quite put
>> my finger on it.
>
> Yes thanks Dan! Will update.
Thanks for all the hints, updated to use the TLH
> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM
> JavaThread from a java.lang.Thread. This is hard to reproduce but a thread
> that has since terminated can provoke a crash. Recognise this and return a
> null ThreadSnapshot.
Kevin Walls has updated the pull req
On Fri, 27 Jun 2025 20:22:12 GMT, Alex Menkov wrote:
> I believe null here is not result of `_thread_h()`, but is returned by
> `java_lang_VirtualThread::continuation(...)` because `_thread_h` is
> lava.lang.Thread object and not java.lang.VirtualThread.
That could only happen if we are dealin
> 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 since the last revisi
> This patch refines Parallel's sizing strategy to improve overall memory
> management and performance.
>
> The young generation layout has been reconfigured from the previous
> `eden-from/to` arrangement to a new `from/to-eden` order. This new layout
> facilitates young generation resizing, si
On Mon, 30 Jun 2025 09:29:28 GMT, Ivan Walulya wrote:
>> Albert Mingkun Yang has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains 25 commits:
>>
>> - Merge branch 'master' into pgc-size-policy
>> - review
>> - cast
>> - remove-youn
On Mon, 30 Jun 2025 09:08:28 GMT, Ivan Walulya wrote:
>>> so that we can do the check after all the GCs
>>
>> Well, not really. In the old impl,
>> `GCOverheadChecker::check_gc_overhead_limit` calls
>> `set_gc_overhead_limit_exceeded` only for full-gc.
>>
>> > But now you only use check_gc_o
> This patch refines Parallel's sizing strategy to improve overall memory
> management and performance.
>
> The young generation layout has been reconfigured from the previous
> `eden-from/to` arrangement to a new `from/to-eden` order. This new layout
> facilitates young generation resizing, si
On Thu, 26 Jun 2025 19:17:11 GMT, Albert Mingkun Yang wrote:
>> This patch refines Parallel's sizing strategy to improve overall memory
>> management and performance.
>>
>> The young generation layout has been reconfigured from the previous
>> `eden-from/to` arrangement to a new `from/to-eden`
On Mon, 19 May 2025 06:00:09 GMT, Albert Mingkun Yang wrote:
>> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 363:
>>
>>> 361: }
>>> 362:
>>> 363: bool ParallelScavengeHeap::check_gc_overhead_limit() {
>>
>> In main-line code, the method `check_gc_overhead_limit` is invoked by
>
On Fri, 27 Jun 2025 19:02:46 GMT, Serguei Spitsyn wrote:
>> Anton Artemov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8284016: Realigned parameters
>
> src/hotspot/share/prims/jvmtiEnvBase.hpp line 511:
>
>> 509: };
>> 510:
>> 511:
> 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 following way:
>
> `XXXDummyClassNameClosure -> XXXDummyC
On Fri, 27 Jun 2025 16:45:44 GMT, Coleen Phillimore wrote:
> I found a couple of places to realign the parameters, but otherwise this
> looks good. I like the new naming conventions. We have a lot of handshakes
> now! Were you able to build shenandoah (not built by default, need to add
> --ena
46 matches
Mail list logo
