On Sat, 11 Jun 2022 08:11:34 GMT, Alan Bateman wrote:
> This test connects to http://openjdk.java.net/ so it's not reliable if the
> host name can't be resolved or a HTTP connection cannot be established. I've
> changed the test to use a local HTTP server so the original test works as
>
On Tue, 7 Jun 2022 00:49:29 GMT, Leonid Mesnik wrote:
> Please review following fix which exclude failing test.
This pull request has now been integrated.
Changeset: 8e10c2bf
Author: Leonid Mesnik
URL:
https://git.openjdk.java.net/jdk/commit/8e10c2bfc73a25d93187b62f5aa8e6210d6fe
> Please review following fix which exclude failing test.
Leonid Mesnik has updated the pull request incrementally with one additional
commit since the last revision:
fixed merge
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/9050/files
- new: ht
> Please review following fix which exclude failing test.
Leonid Mesnik has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains three commits:
- Merge branch 'master' of https://github.com/openjdk/jdk into 8287877
- Merge branch 'mas
On Mon, 9 May 2022 21:26:50 GMT, Alex Menkov wrote:
> isThreadExpected function checks only some known JFR/Graal threads.
> This approach requires to keep this function up to date (add other internal
> threads like usage tracker, loom, etc).
>
> To avoid this updated all tests which use it,
Please review following fix which exclude failing test.
-
Commit messages:
- 8287877: Exclude
vmTestbase/nsk/jvmti/AttachOnDemand/attach022/TestDescription.java until
JDK-8277573 is fixed
Changes: https://git.openjdk.java.net/jdk/pull/9050/files
Webrev:
On Thu, 2 Jun 2022 09:54:31 GMT, Aleksey Shipilev wrote:
> [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496) brought the
> alternative Loom implementation that can be used by ports as the fallback.
> That fallback does not support JVMTI entirely, so lots of tests fail. Some
>
On Tue, 24 May 2022 19:52:57 GMT, Leonid Mesnik wrote:
> Need to use proper synchronization.
>
> The CyclicBarriers might move the thread to WAITING state but not BLOCKED. So
> it should not confuse existing checks.
This pull request has now been integrated.
Changeset: 176
> Need to use proper synchronization.
>
> The CyclicBarriers might move the thread to WAITING state but not BLOCKED. So
> it should not confuse existing checks.
Leonid Mesnik has updated the pull request incrementally with one additional
commit since the last revi
On Wed, 25 May 2022 21:18:24 GMT, master-code-java
wrote:
>> Need to use proper synchronization.
>>
>> The CyclicBarriers might move the thread to WAITING state but not BLOCKED.
>> So it should not confuse existing checks.
>
>
On Tue, 24 May 2022 05:45:17 GMT, Serguei Spitsyn wrote:
> It was a typo when the original CLEARING_MASK was initially introduced:
>
>
> // Mask to clear normal event bits.
> const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL -
> TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;
> // Avoid
Need to use proper synchronization.
The CyclicBarriers might move the thread to WAITING state but not BLOCKED. So
it should not confuse existing checks.
-
Commit messages:
- 8287200
Changes: https://git.openjdk.java.net/jdk/pull/8874/files
Webrev:
On Mon, 9 May 2022 01:36:39 GMT, Leonid Mesnik wrote:
> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI
> capabilities are enabled and --enable-preview.
>
> It restores the same behavior as it was before
> https://bugs.openjdk.java.net/browse/JDK-8227745
On Fri, 20 May 2022 22:27:29 GMT, Leonid Mesnik wrote:
> Sync improved in test
This pull request has now been integrated.
Changeset: 110d9064
Author: Leonid Mesnik
URL:
https://git.openjdk.java.net/jdk/commit/110d906432761482acd2899be1314e075bc21bec
Stats: 7 lines in 1 f
On Mon, 23 May 2022 10:20:39 GMT, Richard Reingruber wrote:
> Could it be that you mean
> [JDK-8264699](https://bugs.openjdk.java.net/browse/JDK-8264699)?
>
Yes, you are right.
> I'm ok with this version of your fix. I'd suggest to change title/synopsis of
> the bug report to better match it
> Sync improved in test
Leonid Mesnik has updated the pull request incrementally with one additional
commit since the last revision:
fix
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/8821/files
- new: https://git.openjdk.java.net/jdk/pull/8821/files/b3f87
On Sat, 21 May 2022 12:14:11 GMT, Richard Reingruber wrote:
> Hi Leonid, if EscapeAnalysis is not disabled, then local objects cannot be
> read per JVMTI if they are scalarized in compiled frames on the heap, right?
> This would be a problem I'd think. Thanks, Richard.
Yes, the fix restores
On Fri, 20 May 2022 20:09:59 GMT, Leonid Mesnik wrote:
>> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI
>> capabilities are enabled and --enable-preview.
>>
>> It restores the same behavior as it was before
>> https://bugs.openjdk.java.
On Fri, 20 May 2022 20:09:59 GMT, Leonid Mesnik wrote:
>> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI
>> capabilities are enabled and --enable-preview.
>>
>> It restores the same behavior as it was before
>> https://bugs.openjdk.java.
Sync improved in test
-
Commit messages:
- 8287103: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java fails
with Xcomp
Changes: https://git.openjdk.java.net/jdk/pull/8821/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8821=00
Issue:
On Fri, 20 May 2022 20:09:59 GMT, Leonid Mesnik wrote:
>> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI
>> capabilities are enabled and --enable-preview.
>>
>> It restores the same behavior as it was before
>> https://bugs.openjdk.java.
ormance in the Presence of JVMTI Agents" is implemented when
> Continuations are enabled.
Leonid Mesnik has updated the pull request incrementally with one additional
commit since the last revision:
2nd v
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/8589/files
- ne
On Thu, 19 May 2022 00:10:15 GMT, Chris Plummer wrote:
> As part of the loom integration, jdb added -trackvthreads and the debug agent
> added "enumeratevthreads". The help text for these options should call out
> that they are Preview Features.
Marked as reviewed by lmesnik (Reviewer).
On Tue, 10 May 2022 20:23:01 GMT, Leonid Mesnik wrote:
> 8283001: windows-x86-cmp-baseline fails in some jvmti native libs
This pull request has now been integrated.
Changeset: 82d25700
Author: Leonid Mesnik
URL:
https://git.openjdk.java.net/jdk/com
On Wed, 27 Apr 2022 23:49:56 GMT, Leonid Mesnik wrote:
> The test failed if GC happens somewhere between
> Class c = Class.forName("TestClass", true, dummyloader);
> and
> OutputAnalyzer output = executor.execute("VM.classloader_stats");
>
> The fix
8283001: windows-x86-cmp-baseline fails in some jvmti native libs
-
Commit messages:
- 8283001
Changes: https://git.openjdk.java.net/jdk/pull/8641/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8641=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8283001
Stats: 85
> To verfiy fix I add System.gc() before
> executor.execute("VM.classloader_stats");
Leonid Mesnik has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. The pull request contains se
On Tue, 10 May 2022 05:14:19 GMT, Alan Bateman wrote:
> I assume you'll remove this test from the-Xcomp exclude list
> (test/hotspot/jtreg/ProblemList-Xcomp.txt) as part of this change,
Sure. The PR reminded me about this. But I need to push problemlist cleanup
first and than merge chnges.
On Mon, 9 May 2022 20:35:57 GMT, Leonid Mesnik wrote:
> The default is required only to set the same depth level in the tree on HTML
> page for default and mixed mode.
This pull request has now been integrated.
Changeset: d347fc12
Author:Leonid Mesnik
URL:
On Mon, 9 May 2022 20:15:21 GMT, Daniel D. Daugherty wrote:
> A trivial fix to nsk_jvmti_threadByName() to solve a native memory leak.
>
> This fix has been stress tested with my
> StressWrapper60M_NMT_detail_suspendthrd003.java
> test and I did NMT detailed monitoring for the whole 60M run.
On Mon, 9 May 2022 21:31:12 GMT, Richard Reingruber wrote:
> Hi Leonid,
>
> have you done some testing?
> [JDK-8227745](https://bugs.openjdk.java.net/browse/JDK-8227745) came with a
> bunch of tests. I wonder how they behave with your change.
>
> Thanks, Richard.
Thank you for looking on
On Mon, 9 May 2022 01:36:39 GMT, Leonid Mesnik wrote:
> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI
> capabilities are enabled and --enable-preview.
>
> It restores the same behavior as it was before
> https://bugs.openjdk.java.net/browse/JDK-8227745
On Mon, 9 May 2022 01:36:39 GMT, Leonid Mesnik wrote:
> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI
> capabilities are enabled and --enable-preview.
>
> It restores the same behavior as it was before
> https://bugs.openjdk.java.net/browse/JDK-8227745
The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI
capabilities are enabled and --enable-preview.
It restores the same behavior as it was before
https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for
Better Performance in the Presence of JVMTI Agents" is
On Fri, 29 Apr 2022 06:33:42 GMT, Serguei Spitsyn wrote:
>> Alan Bateman has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
>
On Fri, 29 Apr 2022 06:43:02 GMT, Serguei Spitsyn wrote:
>> Alan Bateman has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
>
On Fri, 29 Apr 2022 06:09:35 GMT, Serguei Spitsyn wrote:
>> Alan Bateman has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
>
On Fri, 29 Apr 2022 05:48:19 GMT, Serguei Spitsyn wrote:
>> Alan Bateman has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
>
> To verfiy fix I add System.gc() before
> executor.execute("VM.classloader_stats");
Leonid Mesnik has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. The pull request contains three
On Thu, 28 Apr 2022 00:44:18 GMT, Chris Plummer wrote:
>> The test failed if GC happens somewhere between
>> Class c = Class.forName("TestClass", true, dummyloader);
>> and
>> OutputAnalyzer output = executor.execute("VM.classloader_stats");
>>
>> The fix is to make hc static as Chris proposed.
The test failed if GC happens somewhere between
Class c = Class.forName("TestClass", true, dummyloader);
and
OutputAnalyzer output = executor.execute("VM.classloader_stats");
The fix is to make hc static as Chris proposed.
To verfiy fix I add System.gc() before
On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Fri, 8 Apr 2022 22:15:21 GMT, Leonid Mesnik wrote:
> The tests serviceability/jvmti/RedefineClasses start failing in loom-repo
> with CNFE like "java.lang.NoClassDefFoundError:
> jdk/test/lib/compiler/InMemoryJavaCompiler"
>
> It is not a loom specific bug, it mig
On Sat, 9 Apr 2022 00:39:46 GMT, Alex Menkov wrote:
>> The tests serviceability/jvmti/RedefineClasses start failing in loom-repo
>> with CNFE like "java.lang.NoClassDefFoundError:
>> jdk/test/lib/compiler/InMemoryJavaCompiler"
>>
>> It is not a loom specific bug, it might happen in jdk/jdk
The tests serviceability/jvmti/RedefineClasses start failing in loom-repo with
CNFE like "java.lang.NoClassDefFoundError:
jdk/test/lib/compiler/InMemoryJavaCompiler"
It is not a loom specific bug, it might happen in jdk/jdk also.
The workaround is to build some classes explicitly. The fix was
On Thu, 7 Apr 2022 23:29:41 GMT, Leonid Mesnik wrote:
> Tests are updated to ensure that classes are alive while test checks them.
> Actually, fixed by @AlanBateman in repo-loom.
This pull request has now been integrated.
Changeset: a8c87526
Author:Leonid Mesnik
URL:
Tests are updated to ensure that classes are alive while test checks them.
Actually, fixed by @AlanBateman in repo-loom.
-
Commit messages:
- 8284556: Ensure reachability of classes in
runtime/whitebox/TestHiddenClassIsAlive.java and
On Thu, 7 Apr 2022 02:57:29 GMT, Zhengyu Gu wrote:
>> Please review this small patch to fix a possible memory leak.
>>
>> Test:
>> - [x] hotspot_serviceability
>
> Zhengyu Gu has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Fix
Marked as
On Thu, 7 Apr 2022 05:47:56 GMT, Feilong Jiang wrote:
> Add riscv which doesn't have shared memory connector.
> Following tests passed with this patch and
> [CODETOOLS-7903138](https://github.com/openjdk/jtreg/pull/66):
>
> - vmTestbase/nsk/jdb/options/connect/connect003/connect003.java
> -
On Mon, 28 Mar 2022 19:58:59 GMT, Chris Plummer wrote:
> In this test the debuggee creates a couple of threads, and the debugger
> checks to make sure it gets a ThreadStartEvent for each of these threads,
> plus one for the main debuggee thread. Once it has done this, it disables the
>
On Sun, 20 Mar 2022 12:45:34 GMT, Andrey Turbanov wrote:
> In a few places String.indexOf/lastIndexOf methods are called with default
> parameter for index: `0` for `indexOf`, length() for `lastIndexOf`.
> I propose to cleanup such calls. It makes code a bit easier to read. In case
> of
On Sat, 26 Mar 2022 20:50:34 GMT, Andrey Turbanov wrote:
> Let's take advantage of Java 7 languate feature - "Catching Multiple
> Exception Types".
> It simplifies code. Reduce duplication.
> Found by IntelliJ IDEA inspection `Identical 'catch' branches in 'try'
> statement`
Marked as
On Thu, 24 Mar 2022 01:31:42 GMT, Alex Menkov wrote:
> The change reverts the fix for JDK-8282241 which causes regression
Although I think it is a test problem, backout is fine.
-
Marked as reviewed by lmesnik (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7934
On Wed, 9 Mar 2022 20:41:37 GMT, Daniel D. Daugherty wrote:
> A trivial fix to solve a memory leak/memory pinning for long runs of
> suspendthrd003.
>
> See the bug report for the gory analysis details.
>
> This fix was included in my jdk-19+12 stress runs so the updated test was
> executed
On Wed, 9 Mar 2022 10:11:41 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
On Wed, 9 Mar 2022 07:52:37 GMT, Chris Plummer wrote:
>> Fix incorrect assert that assumed the debug agent should never see a
>> ClassPrepare event for a class that it already saw when calling
>> GetLoadedClasses. Details can be found in the bug description.
>
> Chris Plummer has updated the
On Tue, 8 Mar 2022 18:37:45 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
On Mon, 28 Feb 2022 18:49:05 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
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
On Fri, 4 Feb 2022 11:18:39 GMT, Alex Menkov wrote:
> The test expects ClassFileReconstituter restores exactly the same bytes as
> original classbytes.
> This can be wrong if the class has more than 1 method (due to method sorting
> in the VM).
> MethodParametersTarget class had only 1 method
On Fri, 28 Jan 2022 07:49:42 GMT, Chris Plummer wrote:
>> When using -Xcomp, the liveness of some objects the test allocates is more
>> precisely known, allowing the objects to be collected before the test
>> expects. This became an issue in the loom repo because it has changes that
>> result
On Wed, 26 Jan 2022 20:15:59 GMT, Chris Plummer wrote:
> This test is failing in the loom repo when using -Xcomp. The reason is
> because loom introduced doing a full GC in the codecache sweeper, which
> causes some of the Objects referenced by ObjectMonitors to be GC'd. The fix
> is to check
On Fri, 21 Jan 2022 11:04:26 GMT, Aleksey Shipilev wrote:
>> While working on JDK-8280003, I noticed that
>> java/lang/instrument/GetObjectSizeIntrinsicsTest.java does not test arrays
>> with more than 1-byte size elements, and no large arrays (past 4G limit) are
>> tested either. It would be
On Thu, 16 Dec 2021 20:20:41 GMT, Evgeny Nikitin wrote:
>> This PR contains a relatively simple test which verifies that JVMTI-agents
>> are correctly informed about exceptions caught in C2-compiled code. The
>> 8269574 introduces pre-allocated exceptions in some paths, so the test tries
>>
On Thu, 16 Dec 2021 20:16:39 GMT, Evgeny Nikitin wrote:
>> test/hotspot/jtreg/compiler/jvmti/TriggerBuiltinExceptionsTest.java line 28:
>>
>>> 26: * @bug 8269574
>>> 27: * @summary Verifies that exceptions are reported correctly to JVMTI in
>>> the compiled code
>>> 28: * @requires vm.jvmti
On Tue, 14 Dec 2021 01:14:45 GMT, Chris Plummer wrote:
> Include the size of the core file when printing a message that it was found.
Marked as reviewed by lmesnik (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/6822
On Thu, 2 Dec 2021 17:36:43 GMT, Chris Plummer wrote:
> Increase the test timeout to 480 just to make sure we don't see this timeout
> anymore. This same change was already made to TestJmapCoreMetaspace.java a
> long time ago.
Marked as reviewed by lmesnik (Reviewer).
-
PR:
On Tue, 23 Nov 2021 06:49:47 GMT, Leonid Mesnik wrote:
> The agentThread variable might have been set by the new agentThread iteration
> and then deleted in the wrapper from the previous iteration.
>
> The deletion of agentThread variable should be synced with the termination of
On Wed, 24 Nov 2021 02:16:29 GMT, David Holmes wrote:
>> The new thread is started in nsk_jvmti_runAgentThread which is executed
>> under monitors also as well as nsk_jvmti_resetAgentData.
>> Could you please point exact location which is not protected? Seems all
>> thread_state changes and
On Tue, 16 Nov 2021 02:03:46 GMT, Leonid Mesnik wrote:
> The nsk.share.jdi.TestClass1 is used via reflection. The reflective call
> creates MethodHandle and one more reference to TestClass1. So the number of
> expected references should be incremented. Thanks to @plummercj and
ints references to inspected class.
Leonid Mesnik has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains four commits:
- Merge branch 'master' into 8265796
- force GC to clean weak references
- updated
- fix
-
On Tue, 23 Nov 2021 06:49:47 GMT, Leonid Mesnik wrote:
> The agentThread variable might have been set by the new agentThread iteration
> and then deleted in the wrapper from the previous iteration.
>
> The deletion of agentThread variable should be synced with the termination of
The agentThread variable might have been set by the new agentThread iteration
and then deleted in the wrapper from the previous iteration.
The deletion of agentThread variable should be synced with the termination of
the agent thread.
-
Commit messages:
- merge
- fix
Changes:
On Fri, 19 Nov 2021 15:32:24 GMT, Leonid Mesnik wrote:
> The VMObjectAlloc jvmti event was not generated for objects created using
> MethodHanldle. The fix adds posting of the event into Unsafe_AllocateInstance.
>
> While fixing this bug I noticed that event is not posted in th
On Mon, 22 Nov 2021 01:38:47 GMT, David Holmes wrote:
>> Leonid Mesnik has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixed
>
> test/hotspot/jtreg/serviceability/jvmti/VMObjectAlloc/VMObjectAlloc
ment some common way to handle this and cover it
> in another issue.
Leonid Mesnik has updated the pull request incrementally with one additional
commit since the last revision:
fixed
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6478/files
- new: https://git.openjdk.java
On Thu, 9 Sep 2021 06:53:13 GMT, Andrey Turbanov wrote:
> StringBuffer is a legacy synchronized class. StringBuilder is a direct
> replacement to StringBuffer which generally have better performance
Marked as reviewed by lmesnik (Reviewer).
-
PR:
On Wed, 10 Nov 2021 09:33:23 GMT, Andrey Turbanov wrote:
> 8277413: Remove unused local variables in jdk.hotspot.agent
Marked as reviewed by lmesnik (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/6329
On Thu, 18 Nov 2021 09:34:13 GMT, Serguei Spitsyn wrote:
>> The test fails when the target JavaThread has is_exiting() status. In such a
>> case the JvmtiExport::cleanup_thread(this) has already made a clean up of
>> its jvmtiThreadState, so the JavaThread address returned by
>>
The VMObjectAlloc jvmti event was not generated for objects created using
MethodHanldle. The fix adds posting of the event into Unsafe_AllocateInstance.
While fixing this bug I noticed that event is not posted in the intrinsics
version for many functions where it is used. Including but not
On Thu, 18 Nov 2021 04:03:06 GMT, Leonid Mesnik wrote:
>> The nsk.share.jdi.TestClass1 is used via reflection. The reflective call
>> creates MethodHandle and one more reference to TestClass1. So the number of
>> expected references should be incremented. Th
ints references to inspected class.
Leonid Mesnik has updated the pull request incrementally with one additional
commit since the last revision:
force GC to clean weak references
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6402/files
- new: https://git.openjdk.java.ne
On Tue, 16 Nov 2021 02:45:13 GMT, Leonid Mesnik wrote:
>> The nsk.share.jdi.TestClass1 is used via reflection. The reflective call
>> creates MethodHandle and one more reference to TestClass1. So the number of
>> expected references should be incremented. Th
On Wed, 17 Nov 2021 22:21:33 GMT, Serguei Spitsyn wrote:
> The test fails when the target JavaThread has is_exiting() status. In such a
> case the JvmtiExport::cleanup_thread(this) has already made a clean up of its
> jvmtiThreadState, so the JavaThread address returned by _state->get_thread()
On Tue, 16 Nov 2021 02:45:13 GMT, Leonid Mesnik wrote:
>> The nsk.share.jdi.TestClass1 is used via reflection. The reflective call
>> creates MethodHandle and one more reference to TestClass1. So the number of
>> expected references should be incremented. Th
ints references to inspected class.
Leonid Mesnik has updated the pull request incrementally with one additional
commit since the last revision:
updated
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6402/files
- new: https://git.openjdk.java.net/jdk/pull/6402/files/f48
The nsk.share.jdi.TestClass1 is used via reflection. The reflective call
creates MethodHandle and one more reference to TestClass1. So the number of
expected references should be incremented. Thanks to @plummercj and @mlchung
for the investigation.
This fix also prints references to inspected
On Thu, 4 Nov 2021 10:44:41 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This
> scripts verifies that modifiers are in the "blessed" order, and fixes it
> otherwise. I have manually checked the changes made by the script to make
>
On Thu, 7 Oct 2021 21:46:47 GMT, Alex Menkov wrote:
> The fix adds "-XX:PerfMaxStringConstLength" argument running target app
> (default is 1024, 8K should be enough for any environments)
Marked as reviewed by lmesnik (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/5858
On Tue, 5 Oct 2021 22:34:38 GMT, Alex Menkov wrote:
> The change fixes ProcessTools.startProcess "warmup predicate" synchronization
> issue.
> Initially the predicate was called only for STDOUT;
> From jdk8 it's called for STDERR too (but ProcessTools javadoc was not
> updated).
> The fix
On Wed, 20 Oct 2021 18:34:36 GMT, Igor Ignatyev wrote:
> Hi all,
>
> could you please review this tiny patch?
>
> from JBS:
>> serviceability/jvmti/GetObjectSizeClass.java doesn't ignore external flags
>> (where it matters) and hence should not have been marked w/ vm.flagless
>
> Thanks,
>
On Wed, 15 Sep 2021 00:34:08 GMT, Leonid Mesnik wrote:
> 8273921: Refactor NSK/JDI tests to create thread using factory
This pull request has now been integrated.
Changeset: a72c8aa6
Author: Leonid Mesnik
URL:
https://git.openjdk.java.net/jdk/com
On Mon, 20 Sep 2021 22:08:19 GMT, Chris Plummer wrote:
>> I've gotten through about 1/3 of the test plus the new files, so thought I'd
>> pass along my comments so far. Overall it looks good though.
>
>> I've gotten through about 1/3 of the test plus the new files, so thought I'd
>> pass along
On Tue, 21 Sep 2021 07:40:01 GMT, Fairoz Matte wrote:
> 8206438: com/sun/jdi/FieldWatchpoints.java timeout intermittently
I haven't found any analysis for these failures in the bug. Why does increasing
of timeout fix the issue?
-
PR: https://git.openjdk.java.net/jdk/pull/5598
> 8273921: Refactor NSK/JDI tests to create thread using factory
Leonid Mesnik has updated the pull request incrementally with one additional
commit since the last revision:
fixed line numbers after Idea autoimport.
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/5
> 8273921: Refactor NSK/JDI tests to create thread using factory
Leonid Mesnik has updated the pull request incrementally with one additional
commit since the last revision:
space fixed
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/5515/files
- new: ht
On Fri, 17 Sep 2021 20:56:14 GMT, Chris Plummer wrote:
>> Leonid Mesnik has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Renamed JDITask to NamedTask.
>
> test/hotspot/jtreg/vmTestbase/nsk/jdi/Break
On Tue, 21 Sep 2021 03:13:15 GMT, Leonid Mesnik wrote:
>> 8273921: Refactor NSK/JDI tests to create thread using factory
>
> Leonid Mesnik has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Renamed JDITask to NamedTask.
> 8273921: Refactor NSK/JDI tests to create thread using factory
Leonid Mesnik has updated the pull request incrementally with one additional
commit since the last revision:
Renamed JDITask to NamedTask.
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/5515/fi
> 8273921: Refactor NSK/JDI tests to create thread using factory
Leonid Mesnik has updated the pull request incrementally with one additional
commit since the last revision:
More tests fixed.
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/5515/files
- new: ht
1 - 100 of 324 matches
Mail list logo
