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:
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
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
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 =
-
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, dean.l...@oracle.com wrote:
On 10/23/18 2:51 PM, David Holmes wrote:
Hi Dean,
On 24/10/2018 4:05 AM, dean.l...@oracle.com wrote:
On 10/23/18 9:46 AM, dean.l...@oracle.com wrote:
On
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
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
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
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
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, serguei.spit...@oracle.com wrote:
Hi Robbin and David,
There is no JvmtiEnv::SuspendThreadList call in
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:
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
> >
Hi Serguei,
On 24/10/2018 11:00, serguei.spit...@oracle.com 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
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
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
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
Hi, truncate:
On 24/10/2018 02:00, serguei.spit...@oracle.com 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
On 10/23/18 10:34 PM, David Holmes wrote:
On 24/10/2018 8:30 AM, dean.l...@oracle.com wrote:
On 10/23/18 2:51 PM, David Holmes wrote:
Hi Dean,
On 24/10/2018 4:05 AM, dean.l...@oracle.com wrote:
On 10/23/18 9:46 AM, dean.l...@oracle.com wrote:
On 10/22/18 3:31 PM, David Holmes wrote:
Sorry
18 matches
Mail list logo
