On Tue, 22 Feb 2022 19:54:59 GMT, Chris Plummer wrote:
> So you load a class 50 times in separate ClassLoaders, and each load triggers
> the ClassPrepare event, and each time that happens you set a breakpoint on
> each of the 1000 methods, meaning a total of 5000 breakpoints. Doing this
> will
On Wed, 23 Feb 2022 05:56:18 GMT, Chris Plummer wrote:
>> This test has 4 test cases/modes: two core files test cases and two process.
>> Each runs with and w/o `-Xcomp`. The `-Xcomp` test cases are not suppose to
>> run when `-XX:+DeoptimizeALot` is used, because the test does some checks
>>
> This test has 4 test cases/modes: two core files test cases and two process.
> Each runs with and w/o `-Xcomp`. The `-Xcomp` test cases are not suppose to
> run when `-XX:+DeoptimizeALot` is used, because the test does some checks
> that assume certain methods will be compiled. This is handled
On Tue, 22 Feb 2022 21:32:05 GMT, David Holmes wrote:
>> Zhengyu Gu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Simplify classTrack_reset and revert bagSize check
>
> src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 91:
>
>
On Mon, 14 Feb 2022 14:27:45 GMT, Zhengyu Gu wrote:
> There are scenarios that JDWP agent can deadlock on `classTrackLock` monitor.
> Following is the scenario in bug report.
>
> **Java Thread**
> - loads a class and post `JVMTI_EVENT_CLASS_PREPARE` event
> - JDWP event callback handler call
On Wed, 23 Feb 2022 00:51:40 GMT, Daniel D. Daugherty
wrote:
>> I think that is related to why xcomp-process and xcomp-core are not in
>> agreement. Probably also a bug introduced when adding the two core tests
>> (just like the DeoptimizeALot check was done wrong). As a reference, here's
>>
On Tue, 22 Feb 2022 22:38:08 GMT, Chris Plummer wrote:
>> test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java line 61:
>>
>>> 59: * @bug 8193124
>>> 60: * @summary Test the clhsdb 'findpc' command w/o Xcomp on live process
>>> 61: * @requires vm.hasSA
>>
>> Summary says w/o xcomp but no
On Tue, 22 Feb 2022 22:05:21 GMT, Zhengyu Gu wrote:
>> There are scenarios that JDWP agent can deadlock on `classTrackLock`
>> monitor. Following is the scenario in bug report.
>>
>> **Java Thread**
>> - loads a class and post `JVMTI_EVENT_CLASS_PREPARE` event
>> - JDWP event callback handle
On Tue, 22 Feb 2022 21:22:50 GMT, David Holmes wrote:
>> This test has 4 test cases/modes: two core files test cases and two process.
>> Each runs with and w/o `-Xcomp`. The `-Xcomp` test cases are not suppose to
>> run when `-XX:+DeoptimizeALot` is used, because the test does some checks
>> t
> There are scenarios that JDWP agent can deadlock on `classTrackLock` monitor.
> Following is the scenario in bug report.
>
> **Java Thread**
> - loads a class and post `JVMTI_EVENT_CLASS_PREPARE` event
> - JDWP event callback handler calls `classTrack_processUnloads()` to handle
> the event
On Wed, 16 Feb 2022 00:16:48 GMT, Zhengyu Gu wrote:
>> There are scenarios that JDWP agent can deadlock on `classTrackLock`
>> monitor. Following is the scenario in bug report.
>>
>> **Java Thread**
>> - loads a class and post `JVMTI_EVENT_CLASS_PREPARE` event
>> - JDWP event callback handle
On Sat, 19 Feb 2022 04:00:30 GMT, Chris Plummer wrote:
> This test has 4 test cases/modes: two core files test cases and two process.
> Each runs with and w/o `-Xcomp`. The `-Xcomp` test cases are not suppose to
> run when `-XX:+DeoptimizeALot` is used, because the test does some checks
> that
On Mon, 21 Feb 2022 14:43:27 GMT, Johannes Bechberger
wrote:
> Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using the
> newly introduced method `JavaThread::thread_from_jni_environment`.
Please do update. Thanks.
-
PR: https://git.openjdk.java.net/jdk/pull/
On Mon, 21 Feb 2022 10:55:42 GMT, Aleksey Shipilev wrote:
> There are few bugs in SetBreakpoint when it reaches for metaspace allocation,
> notably [JDK-8214992](https://bugs.openjdk.java.net/browse/JDK-8214992) and
> [JDK-8264149](https://bugs.openjdk.java.net/browse/JDK-8264149). This adds
>
On Sat, 19 Feb 2022 14:33:03 GMT, Daniel D. Daugherty
wrote:
> Thumbs up.
Thanks Dan! Can I get one more reviewer please?
-
PR: https://git.openjdk.java.net/jdk/pull/7542
On Thu, 17 Feb 2022 21:32:14 GMT, Chris Plummer wrote:
> There are some minor debug agent changes in the loom repo that are not
> virtual thread specific, and I would like to merge them into the jdk repo.
> This will make the future real merge of loom into jdk a bit cleaner.
>
> The biggest c
On Thu, 17 Feb 2022 17:34:41 GMT, Chris Plummer wrote:
>>> The correctness here depends on exactly how these different functions can
>>> be called. I would have expected the allowed sequence to be: activate ->
>>> 1or more processUnloads -> reset
>>>
>>> but given processUnloads can somehow oc
On Mon, 21 Feb 2022 14:43:27 GMT, Johannes Bechberger
wrote:
> Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using the
> newly introduced method `JavaThread::thread_from_jni_environment`.
Good to know. I will change my PR accordingly (if this ok for you) :)
-
On Fri, 18 Feb 2022 22:27:32 GMT, Sergey Bylokhov wrote:
>> @jerboaa @sspitsyn @alexmenkov thanks for help and reviews
>
> @zzambers do you plan to backport these changes to the old releases and to
> the jdk8 where this test started to fail?
@mrserb, I have just created jdk8 backport yesterday
On Mon, 21 Feb 2022 14:43:27 GMT, Johannes Bechberger
wrote:
> Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using the
> newly introduced method `JavaThread::thread_from_jni_environment`.
I don't like unnecessary special-cases. I added the `ShouldNotReachHere()` due
to f
On Mon, 21 Feb 2022 14:43:27 GMT, Johannes Bechberger
wrote:
> Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using the
> newly introduced method `JavaThread::thread_from_jni_environment`.
To be frank, I would like to integrate your changes into my, because I need a
secon
21 matches
Mail list logo
