On 21/09/2019 4:21 pm, serguei.spit...@oracle.com wrote:
Hi David,
I do not want to insist in the area (Threads_lock use) where you have
much more expertise.
It's more conservatism than expertise :) I had a look through and there
are not too many usages of the Threads_lock in the M&M code an
Hi David,
I do not want to insist in the area (Threads_lock use) where you have
much more expertise.
Also, I agreed that Daniil's webrev.07 version is correct and less risky.
The only my concern was about possible performance impact of linear searches
from the ThreadsList::find_JavaThread_from_
Hi Dan,
On 9/20/19 18:11, Daniel D. Daugherty wrote:
On 9/20/19 9:07 PM, Daniel D. Daugherty wrote:
On 9/20/19 7:15 PM, serguei.spit...@oracle.com wrote:
Hi Dan,
Please, find a minor correction below.
On 9/20/19 2:59 PM, Daniel D. Daugherty wrote:
Daniil,
Thanks for sticking with this pr
Hi David,
I do not want to insist in the area (Threads_lock use) where you have
much more expertise.
Also, I agreed that Daniil's webrev.07 version is correct and less risky.
The only my concern was about possible performance impact of linear searches
from the ThreadsList::find_JavaThread_from_
Hi Dan,
On 9/20/19 18:11, Daniel D. Daugherty wrote:
On 9/20/19 9:07 PM, Daniel D. Daugherty wrote:
On 9/20/19 7:15 PM, serguei.spit...@oracle.com wrote:
Hi Dan,
Please, find a minor correction below.
On 9/20/19 2:59 PM, Daniel D. Daugherty wrote:
Daniil,
Thanks for sticking with this pro
Hi Serguei,
On 21/09/2019 9:50 am, serguei.spit...@oracle.com wrote:
Hi Daniil,
Yes, the Threads_lock is still needed around thread->is_exiting() check
and add_thread().
And if we try to use 2 locks, ThreadTableCreate_lock as in your snippet
and then the nested Threads_lock around thread->
On 9/20/19 9:07 PM, Daniel D. Daugherty wrote:
On 9/20/19 7:15 PM, serguei.spit...@oracle.com wrote:
Hi Dan,
Please, find a minor correction below.
On 9/20/19 2:59 PM, Daniel D. Daugherty wrote:
Daniil,
Thanks for sticking with this project through the many versions.
Sorry this review is
On 9/20/19 7:15 PM, serguei.spit...@oracle.com wrote:
Hi Dan,
Please, find a minor correction below.
On 9/20/19 2:59 PM, Daniel 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:
On 9/20/19 4:50 PM, serguei.spit...@oracle.com wrote:
Hi Daniil,
Yes, the Threads_lock is still needed around thread->is_exiting()
check and add_thread().
And if we try to use 2 locks, ThreadTableCreate_lock as in your snippet
and then the nested Threads_lock around thread->is_exiting() an
Hi Daniil,
Yes, the Threads_lock is still needed around thread->is_exiting() check and
add_thread().
And if we try to use 2 locks, ThreadTableCreate_lock as in your snippet
and then the nested Threads_lock around thread->is_exiting() and
add_thread(java_tid, thread) lines then it will not wor
java.lang.management.ThreadMXBean has two default methods that throw
UnsupportedOperationException:
ThreadInfo[] getThreadInfo(long[], boolean, boolean, int)
ThreadInfo[] dumpAllThreads(boolean, boolean, int)
Without actually testing it, is it safe to assume that since
com.sun.management.Thread
Hi Dan,
Please, find a minor correction below.
On 9/20/19 2:59 PM, Daniel 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 th
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 the changes Serguei
suggested:
1. If racing threads initialize the thread t
Thanks David!
May I get another review?
Best regards
Christoph
> -Original Message-
> From: David Holmes
> Sent: Donnerstag, 19. September 2019 13:56
> To: Langer, Christoph ; Erik Joelsson
> ; Magnus Ihse Bursie
> ; OpenJDK Serviceability d...@openjdk.java.net>; build-dev
> Subject:
Hi Daniil,
You are right that we also have to grab the Threads_lock around the
add_thread call to avoid adding exiting threads.
Let me think a little bit more here.
Thanks,
Serguei
On 9/20/19 08:42, Daniil Titov wrote:
Hi Serguei,
void ThreadTable::lazy_initialize(const ThreadsList *threa
Hi Serguei,
I can change that. Thanks for the review.
Chris
On 9/20/19 1:31 AM, serguei.spit...@oracle.com wrote:
Hi Chris,
This looks good to me.
Just one minor comment:
140 long esti
Hi David,
> >> You seem to have completely missed my point. If the object is local
and
> >> is synchronized upon then the synchronization can be elided (and
should
> >> be) in which case it won't appear in GetOwnedMonitorInfo and so does
not
> >> escape. If the synchroni
Hi Serguei,
> void ThreadTable::lazy_initialize(const ThreadsList *threads) {
> if (_is_initialized) {
> return;
> }
>MutexLocker ml(ThreadTableCreate_lock);
If I understood you correctly in the code snippet you sent you meant to use
Threads_lock, not ThreadTableCreate_lock, ri
On 9/18/19 2:47 PM, Sam Thomas wrote:
> Hi,
>
> I'm trying to understand if a class will load as soon as all the transformers
> return. The aim is to get a class reference of a class I have seen in my
> transformer.
Short answer: no.
Trying to define a class can cause other classes to try to be
Hi Paul,
It might be worth double checking what happens if you create a
MXBean proxy to access the com.sun.management.ThreadMXBean
in a remote server:
https://download.java.net/java/early_access/jdk14/docs/api/java.management/java/lang/management/ManagementFactory.html#getPlatformMXBean(javax.ma
Hi Richard,
On 20/09/2019 6:31 pm, Reingruber, Richard wrote:
Hi David,
> On 20/09/2019 2:42 am, Reingruber, Richard wrote:
> > Hi David,
> >
> > thanks for looking at this issue. And my appologies for the lengthy
mail...
> >
> >> > The JVMTI functions GetOwnedMonitorInfo
Hi Chris,
This looks good to me.
Just one minor comment:
140 long estimatedTime = System.currentTimeMillis() - startTime;
Did you want to name this local "elapsedTime", not
"estimatedTime"? :)
Thanks,
Serguei
Hi David,
> On 20/09/2019 2:42 am, Reingruber, Richard wrote:
> > Hi David,
> >
> > thanks for looking at this issue. And my appologies for the lengthy
mail...
> >
> >> > The JVMTI functions GetOwnedMonitorInfo() and
GetOwnedMonitorStackDepthInfo() can be used to
> >> > r
23 matches
Mail list logo
