)
() -> Files.newBufferedReader(Paths.get(subsystem.path(),
parm {
return bufferedReader.readLine();
} catch (PrivilegedActionException | IOException e) {
return null;
}
}
Best regards,
Daniil
On 12/9/19, 10:51 AM, "Daniil Titov
eption
> so it’s consistent with the other get functions?
>
> Bob.
>
>
>> On Dec 6, 2019, at 8:41 PM, Daniil Titov
wrote:
>>
>> Hi David, Mandy, and Bob,
>>
>> Thank you for reviewing this fix.
>>
>> P
Hi David, Mandy, and Bob,
Thank you for reviewing this fix.
Please review a new version of the fix [1] that includes the following changes
comparing to the previous version of the webrev ( webrev.04)
1. The changes in Javadoc made in the webrev.04 comparing to webrev.03 and to
CSR [3] were
Hi Mandy and Bob,
Thank you for your comments. Please review a new version of the fix [1] that
makes
OperatingSystemImpl methods return -1 if one of the metric has value 0.
As Mandy recommended I also updated the Javadoc for OperatingSystemMXBean
indicating that methods could return -1 if the
tests) passed.
[1] Webrev: http://cr.openjdk.java.net/~dtitov/8226575/webrev.03/
[2] Jira issue: https://bugs.openjdk.java.net/browse/JDK-8226575
[3] CSR: https://bugs.openjdk.java.net/browse/JDK-8228428
Thank you,
Daniil
On 12/4/19, 4:09 PM, "Mandy Chung" wrote:
wapSpaceSize method.
Best regards,
Daniil
On 12/3/19, 7:34 PM, "Daniil Titov" wrote:
Hi Mandy,
Thank you for your comments, please find my answers below.
>> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java
>> this should wrap
oach here.
>>CheckOperatingSystemMXBean.java
>> System.out.println(String.format(...)) can simply be replaced with
>> System.out.format.
I will include this change in the next webrev, thank you!
Best regards,
Daniil
From: Mandy Chung
Date: Tuesday, De
n order to allow you to fallback to
getSystemCpuLoad0.
Bob.
> On Dec 3, 2019, at 2:42 PM, Daniil Titov
wrote:
>
> Please review the change that makes OperatingSystemMXBean methods
return container specific information
nclude this change in the next webrev, thank you!
Best regards,
Daniil
From: Mandy Chung
Date: Tuesday, December 3, 2019 at 4:10 PM
To: Daniil Titov
Cc: OpenJDK Serviceability ,
"jmx-...@openjdk.java.net" , Bob Vandette
Subject: Re: RFR: 8226575: OperatingSystemMXBean shoul
hosts in order to allow you to fallback to
getSystemCpuLoad0.
Bob.
> On Dec 3, 2019, at 2:42 PM, Daniil Titov
wrote:
>
> Please review the change that makes OperatingSystemMXBean methods return
container specific information
Please review the change that makes OperatingSystemMXBean methods return
container specific information
rather than the host based data.
The webrev [1] is based on the code Andrew and Severin initially provided with
some additional changes and combined
with the spec update David made [3].
The
Hi Alex,
The change looks good to me.
Thanks!
Best regards,
Daniil
On 11/15/19, 3:58 PM, "serviceability-dev on behalf of Alex Menkov"
wrote:
Hi all,
Please review small fix for
https://bugs.openjdk.java.net/browse/JDK-8187143
The issue is not reproducible from
Hi Chris,
The change looks good to me.
Thanks!
--Daniil
On 11/12/19, 11:06 AM, "serviceability-dev on behalf of Chris Plummer"
wrote:
Thanks Serguei!
Can I get one more review please?
thanks,
Chris
On 11/8/19 4:00 PM, serguei.spit...@oracle.com wrote:
Hi Alex,
The fix looks good to me.
Thanks!
--Daniil
On 11/12/19, 2:32 PM, "serviceability-dev on behalf of Alex Menkov"
wrote:
Need one more reviewer.
--alex
On 11/01/2019 20:59, serguei.spit...@oracle.com wrote:
> Hi Alex,
>
> It looks good.
>
>
Please a review a changeset below that removes test
sun/tools/jstat/jstatClassloadOutput1.sh from test/jdk/ProblemList.txt.
diff -r f92ef5d182b5 test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt Fri Nov 08 11:41:17 2019 -0500
+++ b/test/jdk/ProblemList.txt Fri Nov 08 22:37:11 2019
ewed CSR as well
>
> --alex
>
> On 10/09/2019 15:45, Daniil Titov wrote:
>> Please review a small fix [1] that removes references to obsolete
>> XDebug flag from JDWP help returned by "java -Xrunjdwp:help" command.
>> A new CSR [2
Please review a small fix [1] that removes references to obsolete XDebug flag
from JDWP help returned by "java -Xrunjdwp:help" command.
A new CSR [2] was created for these changes and needs to be reviewed.
[1] Webrev: http://cr.openjdk.java.net/~dtitov/8227231/webrev.01/
[2] CSR:
the review and discussion process.
Thanks,
Serguei
On 10/1/19 20:20, David Holmes wrote:
> Hi Daniil,
>
> Thanks again for your perseverance with this one.
>
> This looks fine to me.
>
> Thanks,
> David
> -----
Hi David and Robbin,
Thank you for reviewing this fix!
Best regards,
Daniil
On 10/8/19, 1:49 AM, "Robbin Ehn" wrote:
Great, thanks!
/Robbin
On 2019-10-07 18:41, Daniil Titov wrote:
> Hi Robbin,
>
> Yes, I ran my benchmark [1]. Please s
Hi Evgeny,
I will sponsor this change.
Thank you,
Daniil
From: serviceability-dev on
behalf of Daniil Titov
Date: Tuesday, September 24, 2019 at 9:49 PM
To: Evgeny Mandrikov , David Holmes
Cc:
Subject: Re: JDK-8199136: Dead code in
src/jdk.jcmd/share/classes/sun/tools/common
/Robbin
>> Thanks, Robbin
>> >>
>> >> Thank you!
>> >>
>> >> Best regards,
>> >> Daniil
>> >>
>> >> On 10/2/19, 3:26 PM, "David Holmes"
wrote
have not done so, you should test this with the benchmark you
have as
a stress test and see that this does what we think.
Thanks, Robbin
>>
>> Thank you!
>>
>> Best regards,
>> Daniil
>>
>> On 10/2/19, 3:2
successfully passed.
Thank you!
Best regards,
Daniil
On 10/2/19, 3:26 PM, "David Holmes" wrote:
Hi Daniil,
On 3/10/2019 2:21 am, Daniil Titov wrote:
> Hi David and Robbin,
>
> Could we consider making the ServiceThread responsible for the
Thr
----
>
> On 2/10/2019 6:57 am, Daniil Titov wrote:
>> Hello,
>>
>> Please review a new version of the change [1] that fixes the problem
>> with the debugger not stopping in the low memory notification code.
>> The fix moves the send
Please review/approve a CSR request.
The proposed CSR [1] is for adding a new VM option UseNotificationThread
(default true) to opt-out from
the new behavior introduced by the suggested fix [3] for the issue [2] that is
on review now in the separate
email thread [4].
[1] CSR:
>>>
>>> On 2019-10-02 08:46, David Holmes wrote:
>>>> Hi Daniil,
>>>>
>>>> On 2/10/2019 4:13 pm, Daniil Titov wrote:
>>>>> Please review a change that fixes the issue. The problem here is
>>>
Please review a change that fixes the issue. The problem here is that that the
thread is added to the ThreadIdTable (introduced in [3]) while the
Threads_lock is held by
JVM_StartThread. When new thread is added to the thread table the table checks
if its load factor is greater than required
Hello,
Please review a new version of the change [1] that fixes the problem with the
debugger not stopping in the low memory notification code. The fix moves the
send notifications task from
not visible ServiceThread to a new visible NotificationThread. This version of
the change also
Thank you for the explanation!
Have you already pushed this one?
Thanks,
Serguei
On 9/24/19 12:46, Daniil Titov wrote:
> Hi Serguei,
>
> Thank you for reviewing this version of the fix.
>
>> Just one question about ThreadIdTa
t;
> Thanks,
> David
>
> On 25/09/2019 2:36 am, Daniil Titov wrote:
>> Hi Daniel, David and Serguei,
>>
>> Please review a new version of the fix (webrev.08) that as Daniel
suggested
>> renames
>> ThreadTable t
Hi Evgeny,
The change looks good to me.
Thanks!
--Daniil
From: serviceability-dev on
behalf of Evgeny Mandrikov
Date: Tuesday, September 24, 2019 at 1:32 AM
To: David Holmes
Cc:
Subject: Re: RFR: JDK-8199136: Dead code in
Hi Paul,
I have a question about JMM_VERSION. Since the changeset introduces a new
method in the interface
should not JMM_VERSION declared in src/hotspot/share/include/jmm.h be bumped?
Thank you,
--Daniil
On 9/23/19, 5:43 PM, "serviceability-dev on behalf of Hohensee, Paul"
wrote:
expensive and doesn't look as acceptable.
Thanks!
Best regards,
Daniil
On 9/19/19, 6:15 PM, "David Holmes" wrote:
Hi Daniil,
On 20/09/2019 10:30 am, Daniil Titov wrote:
> Hi David and Serguei,
>
> Please review new version of the fix that includes th
successfully passed.
Webrev: https://cr.openjdk.java.net/~dtitov/8185005/webrev.07/
Bug : https://bugs.openjdk.java.net/browse/JDK-8185005
Thank you!
--Daniil
On 9/18/19, 1:01 AM, "serguei.spit...@oracle.com"
wrote:
Hi Daniil,
On 9/17/19 17:13, Daniil Titov wrote:
&g
es and how the proposed implementation satisfies
them.
Best regards,
Daniil
From: "serguei.spit...@oracle.com"
Date: Tuesday, September 17, 2019 at 1:53 AM
To: Daniil Titov , Robbin Ehn
, David Holmes ,
, OpenJDK Serviceability
, "hotspot-runtime-...@openjdk.java.net"
, &quo
not
be added to the table.
Thanks,
David
On 17/09/2019 4:18 am, Daniil Titov wrote:
> Hello,
>
> After investigating with Claes the impact of this change on the
performance (thanks a lot Claes for helping with it!) the conclusion was that
the impact on t
brev.04
[4] https://bugs.openjdk.java.net/browse/JDK-8229391
Thank you,
Daniil
>
> On 8/4/19, 7:54 PM, "David Holmes" wrote:
>
> Hi Daniil,
>
> On 3/08/2019 8:16 am, Daniil
raal. I'm not sure to what extent they are
>>>> waiting on graal fixes or otherwise have a bug filed to eventually
>>>> fix them. Would be nice if we had a process in place to make sure
>>>> these issues are eventually addressed. That fact that tests that
&g
with this.
Maybe have the cache in Java.
Pass in the thread obj into a
java_sun_management_ThreadImpl_getThreadTotalCpuTime3 instead,
thus skipping any look-ups in native.
Thanks, Robbin
On 8/12/19 5:49 AM, Daniil Titov wrote:
> Hi David,
://bugs.openjdk.java.net/browse/JDK-8185005
Webrev: https://cr.openjdk.java.net/~dtitov/8185005/webrev.05/
Thanks,
Daniil
On 8/4/19, 7:54 PM, "David Holmes" wrote:
Hi Daniil,
On 3/08/2019 8:16 am, Daniil Titov wrote:
> Hi David,
>
> Thank you for your deta
Hi Chris,
The change looks good to me.
Thanks,
Daniil
On 8/7/19, 6:57 PM, "serviceability-dev on behalf of Chris Plummer"
wrote:
Hello,
Please review the following:
http://cr.openjdk.java.net/~cjplummer/8227645/webrev.00/webrev.open/
Please review the change that fixes the failing tests when running with Graal.
The issue originally
included several vmTestbase/nsk/jdi tests but only 2 of them still fail:
-
vmTestbase/nsk/jdi/VirtualMachine/instanceCounts/instancecounts003/instancecounts003.java
-
ter ,
252 return _local_table->remove(thread,lookup);
Nit: need space after ,
Thanks,
David
--
> Bug: https://bugs.openjdk.java.net/browse/JDK-8185005
>
> Thanks!
> --Daniil
>
>
> On 7/8/19, 3:24 PM, "Da
-8221730 - https://bugs.openjdk.java.net/browse/JDK-8221730
Best regards,
Daniil
On 7/31/19, 10:42 AM, "serguei.spit...@oracle.com"
wrote:
On 7/31/19 10:32 AM, Daniil Titov wrote:
> Hi Christoph,
>
> There were several issues that the origina
Hi Christoph,
There were several issues that the original change introduced. These issues
were
solved in [1] and [2] and they need to be included in the backport.
[1]: JDK-8225543 - https://bugs.openjdk.java.net/browse/JDK-8225543
[2]: JDK-8221730 -
y, July 29, 2019 at 2:12 AM
To: Daniil Titov , ,
OpenJDK Serviceability ,
"hotspot-runtime-...@openjdk.java.net" ,
"jmx-...@openjdk.java.net" , David Holmes
Subject: Re: RFR: 8185005: Improve performance of
ThreadMXBean.getThreadInfo(long ids[], int maxDepth)
Hi Dani
://bugs.openjdk.java.net/browse/JDK-8170299
Thanks!
--Daniil
On 7/3/19, 11:47 PM, "David Holmes" wrote:
Hi Daniil,
On 4/07/2019 1:04 pm, Daniil Titov wrote:
> Please review the change the fixes the problem with the debugger not
stopping in the low memory noti
9 12:06 PM, Daniil Titov wrote:
> Hi Serguei and David,
>
> Serguei is right, ThreadTable::find_thread(java_tid) cannot return a
JavaThread with an unmatched java_tid.
>
> Please find a new version of the fix that includes the changes Serguei
suggested.
>
>
> On 7/17/19 6:26 PM, Daniil Titov wrote:
>> Hi Chris,
>>
>> Yes, I added output.reportDiagnosticSummary() in webrev-01, but
>> removed it
>> In webrev-02, and later restored it in webrev-03.
>>
output.getExitValue() set to? Also, I think you should print an an
explicit error message indicating you've run out of retries.
thanks,
Chris
On 7/17/19 4:36 PM, Daniil Titov wrote:
> Hi Chris,
>
> output.reportDiagnosticSummary() prints the output f
:
What does output.reportDiagnosticSummary() print out then the port is
already in use, and have you made this happen with your fixes in place?
Chris
On 7/17/19 3:20 PM, Daniil Titov wrote:
> Hi Chris and Alex,
>
> Please review a new version of the fix that mo
242 System.out.println("Test FAILURE on" + name +
> " reason: The expected line \"" + READY_MSG
> 243 + "\" is not present in the process
> output");
> Please add space: "T
12:11 PM, "Chris Plummer" wrote:
Hi Daniil,
It's a little unclear to me why you moved from ProcessThread to
TestProcessThread + Process. An explanation of that would make it easier
to understand many of the changes.
thanks,
Chris
On 7/11/19 10:
Thank you, Chris and Serguei, for reviewing this change!
Best regards,
Daniil
On 7/16/19, 4:58 PM, "Chris Plummer" wrote:
Looks good.
Chris
On 7/16/19 4:12 PM, Daniil Titov wrote:
> Please review the change that fixes the failure of the test.
>
Please review the change that fixes the failure of the test.
The test assumes that the amount of the virtual memory committed to the process
could not
be greater than the total of the RAM and the swap size the machine has,
however, it is not
correct if, for example, the process uses a
Please review the change that fixes an intermittent failure of
sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java
test due to ports collision. The tests finds all network interfaces and for
every interface starts a separate process that tests
the connection to JMX agent server for
here is no need in having " #include
"runtime/mutexLocker.hpp" statement in
"src/hotspot/share/runtime/notificationThread.cpp" file since the header file
"runtime/mutexLocker.hpp" is already included.
Thanks,
Daniil
From: "serguei.spit...
Hi Serguei,
I will put it on hold as David asked but before doing so I just wanted to give
a quick reply to the questions you asked.
Thanks!
Best regards,
Daniil
From: "serguei.spit...@oracle.com"
Date: Monday, July 8, 2019 at 3:09 PM
To: Daniil Titov
e:
Hi Daniil,
On 4/07/2019 1:04 pm, Daniil Titov wrote:
> Please review the change the fixes the problem with the debugger not
stopping in the low memory notification code.
>
> The problem here is that the ServiceThread that calls these MXBean
listeners is hidde
r.hpp"
31 #include "services/gcNotifier.hpp"
32 #include "services/diagnosticArgument.hpp"
33 #include "services/diagnosticFramework.hpp"
Thanks,
Serguei
On 7/3/19 8:04 PM, Daniil Titov wrote:
> Please r
Please review the change the fixes the problem with the debugger not stopping
in the low memory notification code.
The problem here is that the ServiceThread that calls these MXBean listeners is
hidden from the external view that prevents the debugger from stopping in it.
The fix introduces
05
Thanks!
--Daniil
From:
Organization: Oracle Corporation
Date: Friday, June 28, 2019 at 7:56 PM
To: Daniil Titov , OpenJDK Serviceability
, "hotspot-runtime-...@openjdk.java.net"
, "jmx-...@openjdk.java.net"
Subject: Re: RFR: 8185005: Improve performance of
ThreadMXBean
Please review the change that improves performance of ThreadMXBean MXBean
methods returning the
information for specific threads. The change introduces the thread table that
uses ConcurrentHashTable
to store one-to-one the mapping between the thread ids and JavaThread objects
and replaces the
s for looking into this.
>
> Chris
>
> On 6/20/19 6:42 PM, Daniil Titov wrote:
>> Thank you, Chris and Serguei, for reviewing this change.
>>
>> I did more testing with a test program on Linux that repeats
>> get_namespace_pid() method and reads from
ly related to the
current issue or fix, but if you think it might be an issue maybe a bug
should be filed for it.
thanks,
Chris
On 6/19/19 9:02 PM, Daniil Titov wrote:
> Please review the change that fixes an intermittent failure of
serviceability/dcmd/fr
Please review the change that fixes an intermittent failure of
serviceability/dcmd/framework/* tests on Linux platform.
The problem here is that get_namespace_pid() method, that is called by
mmap_attach_shared () that in turn is called by PerfMemory::attach(),
tries to read the namespace pid
Thank you, David, Serguei and Alex, for reviewing this change!
Best regards,
--Daniil
On 6/16/19, 6:15 AM, "David Holmes" wrote:
On 15/06/2019 10:06 am, Daniil Titov wrote:
> Hi Serguei,
>
> The discovery was made by David Holmes. Thank you, David, a lo
19 4:56 PM, Daniil Titov wrote:
> Please review the change that fixes an intermittent issue.
>
> The problem here is that a bitwise-AND (&) operator was used in the
condition instead of a logical AND operator (&&).
> As a result pending_thread->is_thread_f
Please review the change that fixes an intermittent issue.
The problem here is that a bitwise-AND (&) operator was used in the condition
instead of a logical AND operator (&&).
As a result pending_thread->is_thread_fully_suspended() is always evaluated
regardless of the value of at_safepoint
arguments
containing spaces. :(
Thanks for fixing.
David
On 13/06/2019 3:50 am, Daniil Titov wrote:
> Hi David and Serguei,
>
> Could you please have a look at this change? This fix is related with the
changes [3] that you reviewed back in February.
>> Also, this line has unneeded extra "()":
>> + if ((parts[i].startsWith("--module="))) {
Yes, you are right! Thanks! I will remove it before pushing or in the new
version of a webrev if we will come to it.
Thank you!
-Daniil
From: "serguei.spit.
On 6/10/19, 4:56 PM, "serviceability-dev on behalf of Daniil Titov"
wrote:
Please review the change that fixes jcmd process name matching on Linux
platform.
After changes [3] , on Linux platform the proc filesystem is used to find a
Java process, however, sun.tools.Pro
Please review the change that fixes jcmd process name matching on Linux
platform.
After changes [3] , on Linux platform the proc filesystem is used to find a
Java process, however, sun.tools.ProcessHelper class,
introduced in that change, didn't take into account the presence of module
Thank you, Chris, JC, and Gary, for reviewing this change!
Best regards,
Daniil
On 6/7/19, 12:31 PM, "Chris Plummer" wrote:
Looks good.
Chris
On 6/7/19 11:47 AM, Daniil Titov wrote:
> Please review the change that fixes an intermittent failure of t
Please review the change that fixes an intermittent failure of the test when it
is run with Graal on.
The test starts a debuggee and sets the method entry breakpoint for
tc02x004aClass1 class that has only constructor defined.
The debuggee starts 3 threads and each of them creates a new
eed during shutdown of the test.
The only improvement we could add here is
to test if the vm is suspended, but an extra resume does
no harm to ensure the debuggee is running to receive the
quit message.
On 6/5/19, 10:36 PM, Daniil Titov wrote:
> Please re
not
delete the single step request until the event has been received and the
thread is suspended. It can then delete the request and resume the
thread (or all threads if using SUSPEND_ALL). Is there a reason the test
is not already doing this?
thanks,
Chris
Please review a change that fixes the intermittent failure of the test.
The problem here that there is a chance that a single step event had been
posted after the step request was created and before it was deleted.
The fix solves this by ensuring that vm.resume() is called at the end of the
Please review the backport of this fix to JDK 12. The JDK 12 changes applied
mostly smoothly, but one hunk in make/test/JtregNativeJdk.gmk didn't apply
because of changed context lines. That's the only difference.
Webrev: http://cr.openjdk.java.net/~dtitov/backports/jdk12u/8214545/webrev.01/
/JDK-8214545
Thanks!
--Daniil
On 5/20/19, 6:02 PM, "serviceability-dev on behalf of Daniil Titov"
wrote:
Please review a new version of the fix that includes the changes David
suggested.
> The count-- is obvious as it is the loop counter, but it is far from
5:43 PM, "David Holmes" wrote:
Hi Daniil,
cc: Boris and Erik J.
On 20/05/2019 7:12 am, Daniil Titov wrote:
> Please review the change that fixes the failure of
sun/management/jmxremote/bootstrap JMX tests on Windows platform. While
running, these
;Alan Bateman" wrote:
On 19/05/2019 22:12, Daniil Titov wrote:
> Please review the change that fixes the failure of
sun/management/jmxremote/bootstrap JMX tests on Windows platform. While
running, these tests invoke revokeall.exe utility and this utility hangs.
>
&g
Please review the change that fixes the failure of
sun/management/jmxremote/bootstrap JMX tests on Windows platform. While
running, these tests invoke revokeall.exe utility and this utility hangs.
The problem here is that invokeall.exe goes into an endless loop while
iterating over Access
Thank you Chris, David, and JC, for reviewing this change!
Best regards,
Daniil
On 5/15/19, 11:33 PM, "David Holmes" wrote:
Hi Daniil,
That seems fine to me.
Thanks,
David
On 16/05/2019 5:15 am, Daniil Titov wrote:
> Hi David,
://bugs.openjdk.java.net/browse/JDK-8222422
Thanks,
Daniil
On 5/13/19, 2:59 PM, "David Holmes" wrote:
Hi Daniil,
On 14/05/2019 5:56 am, Daniil Titov wrote:
> Hi David,
>
> It seems as the chances that class unloading happens during the life-time
of these test
occurrence of the test
when any ClassUnload event was posted.
On 5/12/19, 3:19 PM, "David Holmes" wrote:
Hi Daniil,
On 12/05/2019 3:14 am, Daniil Titov wrote:
> Hi David,
>
> There are two ways how these reference types (for the classes that bec
e how we can encounter those types while compiling the list in
the debuggee in the first place.
Something seems amiss here ... possibly just my understanding ...
David
> Jc
>
> *From: *Chris Plummer <mailto:chris.plum...@oracle.com>>
> *Dat
Please review the change that fixes an intermittent failure of the test.
The tests checks the implementation of the
com.sun.tools.jdi.ClassLoaderReference class. The problem here is that while
com.sun.tools.jdi.ClassLoaderReferenceImpl.definedClasses() iterates over all
loaded classes to
if you fix this. :)
Thanks,
Serguei
On 5/2/19 6:09 PM, Daniil Titov wrote:
> Hi Serguei,
>
> Please review a new version of the fix that includes the changes you
suggested.
>
> Webrev: http://cr.openjdk.java.net/~dtitov/8222667/webrev.03
> Bug: h
e:
Hi Daniil,
Could you, please, replace 'e' with 'event'?
I've never liked one-letter identifiers.
Other than that it looks good to me.
Thanks,
Serguei
On 5/2/19 9:48 AM, Daniil Titov wrote:
> Hi Gary,
>
> Please review a new version of t
id you use some tracing option,
or did you add a diagnostic to dump the
stray event?
On 5/2/19, 12:48 PM, Daniil Titov wrote:
> Hi Gary,
>
> Please review a new version of the webrev that adds the comment you
mentioned.
>
> Regarding the
the tests,
it might be useful to provide some reusable filters. $.02
On 5/1/19, 9:07 PM, Daniil Titov wrote:
> Please review the change that fixes the test that intermittently fails
with Graal on.
>
> The test tests addThreadFilter() method for
com.sun.jdi.Threa
Please review the change that fixes the test that intermittently fails with
Graal on.
The test tests addThreadFilter() method for com.sun.jdi.ThreadStartRequest
class. It starts a debuggee, creates ThreadStartRequest, enables it, and calls
addThreadFilter(). The test also uses breakpoints to
Thank you, Dean, JC, Chris, and Serguei, for reviewing this change!
Best regards,
Daniil
From: Chris Plummer
Date: Tuesday, April 30, 2019 at 11:39 AM
To: Daniil Titov
Subject: Re: FW: 8222821: com/sun/jdi/ExceptionEvents.java failed
Looks good.
Chris
From
Thank you, Serguei and JC, for reviewing this change!
Best regards,
Daniil
From: Jean Christophe Beyler
Date: Thursday, April 25, 2019 at 5:32 PM
To: Serguei Spitsyn
Cc: Daniil Titov , OpenJDK Serviceability
Subject: Re: RFR: 8222749:
vmTestbase/nsk/jdi/ThreadStartRequest
Please review the change that fixes an intermittent failure of the test when
running with Graal on.
The test creates exception requests for different kinds of exceptions and
errors, starts the debuggee that throws an exception, and listens for exception
events. If the number of received
Please review the change that fixes this test when it is run with Graal on.
The test starts the debugee, creates multiple thread start requests, tells the
debuggee to start a new thread, and listens for the thread start events
received. If the number of the received thread start events doesn't
ooks good to me too :-)
> Jc
>
> On Tue, Apr 9, 2019 at 7:01 PM <mailto:serguei.spit...@oracle.com>> wrote:
>
> Hi Daniil,
>
> It looks good.
>
> Thanks,
> Serguei
>
>
>
Please review the change that fixes intermittent failure of the test when
running with Graal on.
The problem here is the similar to the one fixed in JDK-8218401, the callbacks
this test enables keep processing events and perform JVMTI calls after VM is
terminated. The fix ensures that the test
Thank you, JC and David, for reviewing this change!
Best regards,
-Daniil
From: Jean Christophe Beyler
Date: Friday, April 5, 2019 at 9:40 AM
To: David Holmes
Cc: Daniil Titov , OpenJDK Serviceability
, Thomas Stüfe
Subject: Re: 8221730: jcmd process name matching broken
Hi Daniil
101 - 200 of 373 matches
Mail list logo
