On Wed, 21 Apr 2021 18:40:16 GMT, Chris Plummer wrote:
> > > My concerns with your proposed testing is that it always targets the same
> > > application with the same heap, and does not read/process the hprof file
> > > to make sure it is not corrupt.
> >
> >
> > Hmm, I agree, I will do more
> This PR revise the help message of the `parallel=[N]` option of command
> `jmap -histo`. It mainly comes from the discussion at
> https://github.com/openjdk/jdk/pull/2379#issuecomment-782609582 and
> https://github.com/openjdk/jdk/pull/2261#issuecomment-823623186.
Lin Zang has updated the
On Wed, 21 Apr 2021 21:22:50 GMT, Daniel D. Daugherty
wrote:
>> I'm updating the runtime/Thread/SuspendAtExit.java test:
>>
>> - switch from java.lang.Thread.suspend() to JVM/TI SuspendThread()
>> - switch from java.lang.Thread.resume() to JVM/TI ResumeThread()
>> - switch from counter-based
On Wed, 21 Apr 2021 19:37:28 GMT, Daniel D. Daugherty
wrote:
>> test/hotspot/jtreg/runtime/Thread/libSuspendAtExit.cpp line 2:
>>
>>> 1: /*
>>> 2: * Copyright (c) 2001, 2021, Oracle and/or its affiliates. All rights
>>> reserved.
>>
>> Copyright year should just be 2021.
>
> I copied this
On Wed, 7 Apr 2021 00:12:11 GMT, Yasumasa Suenaga wrote:
>> `jhsdb debugd` will start RMI registry by default, but we want to prevent it
>> due to port confliction in some cases. We can control it with
>> `sun.jvm.hotspot.rmi.startRegistry` system property. However we have no way
>> to set it
> I'm updating the runtime/Thread/SuspendAtExit.java test:
>
> - switch from java.lang.Thread.suspend() to JVM/TI SuspendThread()
> - switch from java.lang.Thread.resume() to JVM/TI ResumeThread()
> - switch from counter-based to time-based testing
> - improve error checking since we're now using
On Thu, 15 Apr 2021 03:14:34 GMT, Serguei Spitsyn wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Updated the fix accordingly feedback
>
> test/jdk/java/lang/instrument/ATransformerManagementTestCase.java line 125:
> The test actually failed starting from jdk13, but the error is masked by
> JDK-8264667 (and shell part of the test didn't verify result of the java
> execution)
> The fix:
> - updates JvmtiClassFileReconstituter to add attributes in the same order as
> javac does
> - makes the test java
On Wed, 21 Apr 2021 20:46:43 GMT, Alex Menkov wrote:
>> test/jdk/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.java
>> line 186:
>>
>>> 184: int lineNum = 0;
>>> 185: for (String line: out1) {
>>> 186: if (expectedDiffenent(line)) {
>>
>> Is it
On Wed, 21 Apr 2021 05:50:01 GMT, David Holmes wrote:
>> I'm updating the runtime/Thread/SuspendAtExit.java test:
>>
>> - switch from java.lang.Thread.suspend() to JVM/TI SuspendThread()
>> - switch from java.lang.Thread.resume() to JVM/TI ResumeThread()
>> - switch from counter-based to
On Wed, 21 Apr 2021 05:47:35 GMT, Lin Zang wrote:
>> This PR revise the help message of the `parallel=[N]` option of command
>> `jmap -histo`. It mainly comes from the discussion at
>> https://github.com/openjdk/jdk/pull/2379#issuecomment-782609582 and
>>
On Wed, 21 Apr 2021 05:56:21 GMT, Lin Zang wrote:
> > My concerns with your proposed testing is that it always targets the same
> > application with the same heap, and does not read/process the hprof file to
> > make sure it is not corrupt.
>
> Hmm, I agree, I will do more test and update
On 20/04/2021 21:26, Rafael Winterhalter wrote:
I have earlier proposed to offer a "jdk.test" module that
offers the Instrumentation instance via a simple API similar to Byte
Buddy's. The JVM would not load this module unless requested on the command
line. Build tools like Maven's surefire or
Hi Ron,
we certainly do come from different backgrounds and therefore perspectives,
I find this exchange of perspective to be the main advantage of this open
mailing list.
I do believe that I have an understanding of your angle, I tried to give my
feedback since before Java 9 introduced the
I think you’re coming to this discussion with a very different perspective from
us, which
makes understanding what is or isn’t on the table unclear, and also steers the
ideas in
directions that are different from the one we’re going.
Our goal is not to maintain some status quo until such time
On Wed, 21 Apr 2021 14:42:39 GMT, Maurizio Cimadamore
wrote:
> Compiler changes look good (I have not checked SymbolGenerator).
>
> Why were some tests removed?
thanks for the review. The removed tests were already covered in langtools
regression tests, so I only removed duplicated tests
On Fri, 16 Apr 2021 03:35:06 GMT, Vicente Romero wrote:
>> Please review this PR that intents to make sealed classes a final feature in
>> Java. This PR contains compiler and VM changes. In line with similar PRs,
>> which has made preview features final, this one is mostly removing preview
>>
On Wed, 21 Apr 2021 13:25:53 GMT, Richard Reingruber wrote:
> I've followed the discussion and the increments. Still looks very good to me
Thank you!
-
PR: https://git.openjdk.java.net/jdk/pull/3191
On Wed, 21 Apr 2021 07:59:09 GMT, Robbin Ehn wrote:
>> A suspend request is done by handshaking thread target thread(s). When
>> executing the handshake operation we know the target mutator thread is in a
>> dormant state (as in safepoint safe state). We have a guarantee that it will
>> check
On Wed, 21 Apr 2021 13:17:02 GMT, Daniel D. Daugherty
wrote:
> Reviewed the v11 and v12 incrementals.
> Still a thumbs up.
Thank you!
-
PR: https://git.openjdk.java.net/jdk/pull/3191
On Wed, 21 Apr 2021 07:59:09 GMT, Robbin Ehn wrote:
>> A suspend request is done by handshaking thread target thread(s). When
>> executing the handshake operation we know the target mutator thread is in a
>> dormant state (as in safepoint safe state). We have a guarantee that it will
>> check
On Mon, 11 Jan 2021 18:39:41 GMT, Lutz Schmidt wrote:
> Hi,
> may I please ask the community to review this small fix? It closes another
> hole in AsyncGetCallTrace().
> Thanks a lot!
> Lutz
This pull request has been closed without being integrated.
-
PR:
On Wed, 21 Apr 2021 07:59:09 GMT, Robbin Ehn wrote:
>> A suspend request is done by handshaking thread target thread(s). When
>> executing the handshake operation we know the target mutator thread is in a
>> dormant state (as in safepoint safe state). We have a guarantee that it will
>> check
> A suspend request is done by handshaking thread target thread(s). When
> executing the handshake operation we know the target mutator thread is in a
> dormant state (as in safepoint safe state). We have a guarantee that it will
> check it's poll before leaving the dormant state. To stop the
On Tue, 20 Apr 2021 18:09:07 GMT, Patricio Chilano Mateo
wrote:
> Latest version LGTM!
>
> Thanks,
> Patricio
Thanks
-
PR: https://git.openjdk.java.net/jdk/pull/3191
On Wed, 21 Apr 2021 04:32:36 GMT, David Holmes wrote:
> Looks good.
Thanks
-
PR: https://git.openjdk.java.net/jdk/pull/3191
On Wed, 21 Apr 2021 04:39:35 GMT, David Holmes wrote:
>> Borrowing the HandshakeState lock does create an artificial coupling here.
>> I'd prefer to see this API in a more natural place with friendship used to
>> access the mechanism as needed. Future cleanup though.
>
> Also I think you'd
On Mon, 19 Apr 2021 19:15:18 GMT, Daniel D. Daugherty
wrote:
> I'm updating the runtime/Thread/SuspendAtExit.java test:
>
> - switch from java.lang.Thread.suspend() to JVM/TI SuspendThread()
> - switch from java.lang.Thread.resume() to JVM/TI ResumeThread()
> - switch from counter-based to
28 matches
Mail list logo
