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 Con
;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.
>
>
On 5/19/19, 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,
/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
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/
Bu
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 l
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-dev@openjdk.java.net"
Subject: Re: RFR: 8185005: Improve performance of
ThreadMXBean
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 new
ces/lowMemoryDetector.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 wrot
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
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
there 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.sp
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 a
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 memory-map
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.
>
n 7/17/19, 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
> 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: &q
wrote:
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 moves
s. What is
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()
>
> 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.
>>
On 6/29/19 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
://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 notification code.
y, July 29, 2019 at 2:12 AM
To: Daniil Titov , ,
OpenJDK Serviceability ,
"hotspot-runtime-...@openjdk.java.net" ,
"jmx-dev@openjdk.java.net" , David Holmes
Subject: Re: RFR: 8185005: Improve performance of
ThreadMXBean.getThreadInfo(long ids[], int maxDepth)
Hi Daniil,
ableEntry* entry = new ThreadTableEntry(tid,java_thread);
Nit: need space after ,
252 return _local_table->remove(thread,lookup);
Nit: need space after ,
Thanks,
David
--
> Bug: https://bugs.openjdk.java.net/browse/JDK-8185005
>
> Thanks!
https://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
sue 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, Robbin,
05/webrev.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, D
ontain threads that will 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
he possible cases 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.ne
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
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 i
er.
Thanks!
Best regards,
Daniil
From: "serguei.spit...@oracle.com"
Date: Thursday, September 19, 2019 at 10:30 PM
To: Daniil Titov , Robbin Ehn
, David Holmes ,
, OpenJDK Serviceability
, "hotspot-runtime-...@openjdk.java.net"
, "jmx-dev@openjdk.java.net&qu
iel D. Daugherty" wrote:
Daniil,
Thanks for sticking with this project through the many versions.
Sorry this review is late...
On 9/19/19 8:30 PM, Daniil Titov wrote:
> Hi David and Serguei,
>
> Please review new version of the fix that includes
hat happens if there is no thread with the specified tid in ThreadIdTable?
Is it possible?
Thanks,
Serguei
On 9/24/19 9:36 AM, Daniil Titov wrote:
> Hi Daniel, David and Serguei,
>
> Please review a new version of the fix (webrev.08) that as Daniel
suggest
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 to Th
ou 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
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 introd
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
; /Robbin
>>>
>>> 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/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: https://bugs
----
>
> 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
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
Thread
nd if you 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
/Robbin
>> Thanks, Robbin
>> >>
>> >> Thank you!
>> >>
>> >> Best regards,
>> >> Daniil
>> >>
>> >> On 10/2/19, 3:26 PM, "David Holmes"
wrote:
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
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
> -----
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
entical to the
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
stem.out.format.
I will include 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-dev@openjdk.java.net" , Bob Vandette
Subject: Re: RFR: 8226575: Op
the 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 specif
it is a better approach 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 Chu
FreeSwapSpaceSize 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
ment 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:
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
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 disc
on
> 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.
>>
>&
)
() -> 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
= (udiff / (double)tdiff);
296 user_load = MAX(user_load, 0.0);
297 user_load = MIN(user_load, 1.0);
298 }
299 }
Best regards,
Daniil
On 12/8/19, 8:49 PM, "David Holmes" wrote:
Hi Daniil,
On 7/12/2019 11:41 am, Daniil T
/webrev.06/
[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/9/19, 1:55 PM, "Mandy Chung" wrote:
On 12/9/19 10:51 AM, Daniil Titov wrote:
> Hi Mandy and Bob,
Hi David,
> Please file a follow up RFE to look into this.
I created an issue to follow this up [1]
[1] https://bugs.openjdk.java.net/browse/JDK-8235681
Thank you,
Daniil
On 12/10/19, 2:11 AM, "David Holmes" wrote:
On 10/12/2019 5:31 am, Daniil Titov wrote:
t;OperatingSystemMXBean.getTotalSwapSpaceSize:
%d", osBean.getTotalSwapSpaceSize()));
41 log(String.format("OperatingSystemMXBean.getFreeSwapSpaceSize:
%d", osBean.getFreeSwapSpaceSize()));
42 log(String.format("OperatingSystemMXBean.getCpuLoad:
reeSwapSpaceSize()));
42 log(String.format("OperatingSystemMXBean.getCpuLoad: %f",
osBean.getCpuLoad()));
43 log(String.format("OperatingSystemMXBean.getSystemCpuLoad: %f",
osBean.getSystemCpuLoad()));
Thanks,
Serguei
trics are returned) is covered by
JDK-8235522.
Revising all concerns in JDK-8235522 sounds good to me.
Thanks,
Serguei
On 12/10/19 10:29, Daniil Titov wrote:
> Hi Serguei,
>
>>Do we need to check if the (limit - memLimit) value is negativ
Typo fixed...
.. that the only "volatile" metrics are "usage" ones ( memoryUsage and
*memoryAndSwapUsage*).
Best regards,
Daniil
On 12/11/19, 3:33 PM, "Daniil Titov" wrote:
Hi Serguei,
Thank you for reviewing this change.
Just wanted
s done for JDK14!
Bob.
> On Dec 11, 2019, at 12:12 PM, Daniil Titov
wrote:
>
> Hi Serguei,
>
> Thank you for your comments. I will correct this nits before pushing the
changes.
>
> Hi Bob and David,
>
>> [Man
Please review a change [1] that removes constant
javax.management.remote.rmi.RMIConnectorServer.CREDENTIAL_TYPE.
This constant represents the name of the attribute that specifies a list of
class names acceptable to the RMIServer.newClient()
remote method call. This constant was superseded by
RM
st regards,
-- daniel
On 11/01/2020 04:52, Daniil Titov wrote:
> Please review a change [1] that removes constant
javax.management.remote.rmi.RMIConnectorServer.CREDENTIAL_TYPE.
> This constant represents the name of the attribute that specifies a list
of class nam
Please review a change that removes unnecessary workaround in
UnixOperatingSystem.c.
It looks as this workaround
if (pticks->usedKernel < tmp.usedKernel) {
kdiff = 0;
}
was added to compensate a missed initialization of counters.jvmTicks that
resulted in the new
counters being comp
fix a different issue, but it's already
initialized to 0 at the start of the function.
thanks,
Chris
On 1/17/20 7:10 PM, Daniil Titov wrote:
> Please review a change that removes unnecessary workaround in
UnixOperatingSystem.c.
>
> It looks
Thank you Alex and Chris for reviewing this change!
Best regards,
Daniil
On 1/24/20, 10:38 AM, "Alex Menkov" wrote:
+1
--alex
On 01/22/2020 19:02, Chris Plummer wrote:
> Looks good.
>
> Chris
>
> On 1/22/20 3:30 PM, Dani
70 matches
Mail list logo
