Hi, truncate:
On 24/10/2018 02:00, [email protected] wrote:
One thing I noticed which Robbin should be able to expand upon is that Thread
101 is terminating and has called ThreadsSMRSupport::smr_delete and is
blocked here:
// Wait for a release_stable_list() call before we check ag
Thanks Robbin! So you're no allowed to request a VM operation if you
hold a ThreadsListHandle ? I suppose that is no different to not being
able to request a VM operation whilst holding the Threads_lock.
I suspect before ThreadSMR this may have been a case where we weren't
ensuring a target th
Hi Robbin and David,
There is no JvmtiEnv::SuspendThreadList call in the dumped stack traces.
But there is an instance of the JvmtiEnv::SuspendThread which seems to
be supporting your theory:
Thread 136 (Thread 0x2ae494100700 (LWP 28023)):
#0 0x2ae3927b5945 in pthread_cond_wait@@GLIBC_2.3
On 24/10/2018 09:46, David Holmes wrote:
Thanks Robbin! So you're no allowed to request a VM operation if you hold a
ThreadsListHandle ? I suppose that is no different to not being able to request
a VM operation whilst holding the Threads_lock.
Yes, exactly.
/Robbin
I suspect before Thread
Hi Serguei,
On 24/10/2018 11:00, [email protected] wrote:
Hi Robbin and David,
There is no JvmtiEnv::SuspendThreadList call in the dumped stack traces.
But there is an instance of the JvmtiEnv::SuspendThread which seems to be
supporting your theory:
Sorry, I did mean any place we ta
Hi again,
On Tue, 2018-10-23 at 15:37 +0200, Thomas Schatzl wrote:
> Hi Paul,
>
> sorry for the long wait.
>
> On Mon, 2018-10-08 at 23:49 +, Hohensee, Paul wrote:
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8196989
> > CSR: https://bugs.openjdk.java.net/browse/JDK-8196991
> > Webrev
Hi,
On Wed, 2018-10-24 at 11:57 +0200, Thomas Schatzl wrote:
> Hi again,
>
> On Tue, 2018-10-23 at 15:37 +0200, Thomas Schatzl wrote:
> > Hi Paul,
> >
> > sorry for the long wait.
> >
> > On Mon, 2018-10-08 at 23:49 +, Hohensee, Paul wrote:
> > > Bug: https://bugs.openjdk.java.net/browse/
Hi sorry, the assert should be
assert(!t->have_threads_list(),)
We should not have a threads list :)
/Robbin
On 24/10/2018 11:18, Robbin Ehn wrote:
Hi Serguei,
On 24/10/2018 11:00, [email protected] wrote:
Hi Robbin and David,
There is no JvmtiEnv::SuspendThreadList call in th
Hi JC,
Overall looks good. Just a couple of minor things. I don't need to
see another webrev.
In Abort.cpp, Callbacks.cpp, ConcreteKlassFilter.cpp,
HeapFilter.cpp.frames, NonConcreteKlassFilter.cpp, and
threadend002.cpp.frames you need to add a
Hi Chris, thanks for the review!
I created https://bugs.openjdk.java.net/browse/JDK-8212939 for the
remaining spaces missing after an if/while/for/switch and between ){ in
the case of an if:
jint Agent_Initialize(JavaVM *vm, char *options, void *reserved){
Thanks,
Jc
On Wed, Oct 24, 2018 at 10
Hi all,
Anybody else want to review this? We can close the book on spaces
before/after () once this one goes in :)
Jc
On Mon, Oct 22, 2018 at 1:37 PM Alex Menkov
wrote:
> LGTM.
>
> --alex
>
> On 10/22/2018 11:29, JC Beyler wrote:
> > Hi all,
> >
> > Here is the next webrev (second out of 3) to
Leonid confirmed this deadlock is not reproducible if the Kitchensink
agent_sampler is disabled.
Also, applying the patch from Robbin (with agent_sampler enabled) hit
new assert
that has caught another case in JvmtiEnv::GetStackTrace with the same
pattern:
With proposed patch issue reproduced
On 10/23/18 11:04 PM, Mandy Chung wrote:
On 10/23/18 10:34 PM, David Holmes wrote:
On 24/10/2018 8:30 AM, [email protected] wrote:
On 10/23/18 2:51 PM, David Holmes wrote:
Hi Dean,
On 24/10/2018 4:05 AM, [email protected] wrote:
On 10/23/18 9:46 AM, [email protected] wrote:
On 10
Hi Jc,
It looks great!
Your AI-enabled conversion scripts are smart! :)
Thanks,
Serguei
On 10/24/18 09:40, JC Beyler wrote:
Hi all,
Here is the first webrev to ext
Hi JC,
Overall looks pretty good:
I see some cases of changes on lines where there is an assignment
in a conditional. Will these conflict with your other webrev?
if (!NSK_JNI_VERIFY(jni, (root =
- jni->GetStaticObject
This patch fixes the regression introduced by JDK-8198253 in 11.
It turns out that NetBeans uses the internal sun.management API to
convert ThreadInfo to CompositeData for performance reason.
ThreadInfoCompositeData::toCompositeData is no longer used
in JDK since JMX added the MXBean support in JD
Hi Sven,
Do you have the performance numbers comparing the use of this
internal API vs MBeanServer::invoke to convert ThreadInfo to
CompositeData?
ThreadInfo is converted to an open data via MXBean support
but not toCompositeData method NB is using.
CompositeData is designed for interoperability
Hi JC,
webrev.00 is fine since you have bugs filed for the rest.
thanks,
Chris
On 10/24/18 7:54 PM, JC Beyler wrote:
Hi Chris,
I inlined my answers:
18 matches
Mail list logo
