Hi Roman,
I'm okay with fix.
Thanks,
Serguei
On 3/26/20 17:15, serguei.spit...@oracle.com wrote:
Hi Roman,
Yes. Thank you for the explanation.
Thanks,
Serguei
On 3/26/20 01:44, Roman Kennke wrote:
That was in the previous implementation: I got a condition wrong in the
table lookup (as not
Hi Roman,
Yes. Thank you for the explanation.
Thanks,
Serguei
On 3/26/20 01:44, Roman Kennke wrote:
That was in the previous implementation: I got a condition wrong in the
table lookup (as noted by Serguei), and this prevented any
class-unload-events from getting out. I have fixed this, but fo
Hi Roman,
Yes. Thank you.
Chris
On 3/26/20 1:44 AM, Roman Kennke wrote:
That was in the previous implementation: I got a condition wrong in the
table lookup (as noted by Serguei), and this prevented any
class-unload-events from getting out. I have fixed this, but found other
problems in that i
That was in the previous implementation: I got a condition wrong in the
table lookup (as noted by Serguei), and this prevented any
class-unload-events from getting out. I have fixed this, but found other
problems in that implementation (deadlocks and a crash).
The current implementation has none
Hi Roman,
It passed all my testing. I think before you push Serguei has a question
regarding an issue you brought up a while back. You mentioned that you
weren't getting some events, and suddenly started seeing them. We were
discussing it today and it was unclear if this was an issue you were
The new job finished, its ID is:
mach5-one-rkennke-JDK-8227269-2-20200325-2027-9716289
Thank you,
Roman
> Yes, please submit a new job. I'll start my testing once I see that the
> builds are done.
>
> Chris
>
> On 3/25/20 12:59 PM, Roman Kennke wrote:
>> Hi Chris,
>>
>> Apparently we can get
Yes, please submit a new job. I'll start my testing once I see that the
builds are done.
Chris
On 3/25/20 12:59 PM, Roman Kennke wrote:
Hi Chris,
Apparently we can get into classTrack_reset() before calling activate(),
and we're seeing a null deletedSignatureBag. A simple NULL-check around
th
Hi Chris,
Apparently we can get into classTrack_reset() before calling activate(),
and we're seeing a null deletedSignatureBag. A simple NULL-check around
the cleaning routine fixes the problem for me.
http://cr.openjdk.java.net/~rkennke/JDK-8227269/webrev.08/
Should I post another submit-repo j
Hi Roman,
com/sun/jdi/JdwpAllowTest.java
crashed on many runs:
Stack: [0x7fbb790f9000,0x7fbb791fa000], sp=0x7fbb791f8af0, free space=1022k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native cod
Hi Chris,
> Regarding the new assert:
>
> 105 if (gdata && gdata->assertOn) {
> 106 // Check this is not already tagged.
> 107 jlong tag;
> 108 error = JVMTI_FUNC_PTR(trackingEnv, GetTag)(env, klass, &tag);
> 109 if (error != JVMTI_ERROR_NONE) {
> 110
Hi Roman,
Regarding the new assert:
105 if (gdata && gdata->assertOn) {
106 // Check this is not already tagged.
107 jlong tag;
108 error = JVMTI_FUNC_PTR(trackingEnv, GetTag)(env, klass, &tag);
109 if (error != JVMTI_ERROR_NONE) {
110 EXIT_E
Hi Sergei,
> The fix looks pretty clean now.
> I also like new name of the lock.:)
Thank you!
> Just one comment below.
>
> http://cr.openjdk.java.net/~rkennke/JDK-8227269/webrev.06/src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c.frames.html
>
> 110 if (tag != 0l) {
> 111 return; // Alrea
Hi Roman,
The fix looks pretty clean now.
I also like new name of the lock.:)
Just one comment below.
http://cr.openjdk.java.net/~rkennke/JDK-8227269/webrev.06/src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c.frames.html
110 if (tag != 0l) {
On 3/24/20 14:47, Chris Plummer wrote:
On 3/24/20 2:46 PM, serguei.spit...@oracle.com wrote:
On 3/24/20 14:39, Chris Plummer wrote:
On 3/24/20 1:45 PM, Roman Kennke wrote:
I assume JVMTI maintains separate tagging data for each agent so
having
two agents doing tagging won't result in confusion
On 3/24/20 2:46 PM, serguei.spit...@oracle.com wrote:
On 3/24/20 14:39, Chris Plummer wrote:
On 3/24/20 1:45 PM, Roman Kennke wrote:
I assume JVMTI maintains separate tagging data for each agent so
having
two agents doing tagging won't result in confusion. I didn't
actually
find this in the s
On 3/24/20 14:39, Chris Plummer wrote:
On 3/24/20 1:45 PM, Roman Kennke wrote:
I assume JVMTI maintains separate tagging data for each agent so
having
two agents doing tagging won't result in confusion. I didn't actually
find this in the spec. Would be nice to confirm that it is the case.
Howev
On 3/24/20 1:45 PM, Roman Kennke wrote:
I assume JVMTI maintains separate tagging data for each agent so having
two agents doing tagging won't result in confusion. I didn't actually
find this in the spec. Would be nice to confirm that it is the case.
However, your implementation does seem to conf
>>> I assume JVMTI maintains separate tagging data for each agent so having
>>> two agents doing tagging won't result in confusion. I didn't actually
>>> find this in the spec. Would be nice to confirm that it is the case.
>>> However, your implementation does seem to conflict with other uses of
>>
Hi Roman,
On 3/24/20 1:56 AM, Roman Kennke wrote:
Hi Chris,
I assume JVMTI maintains separate tagging data for each agent so having
two agents doing tagging won't result in confusion. I didn't actually
find this in the spec. Would be nice to confirm that it is the case.
However, your implement
Hi Chris,
> I assume JVMTI maintains separate tagging data for each agent so having
> two agents doing tagging won't result in confusion. I didn't actually
> find this in the spec. Would be nice to confirm that it is the case.
> However, your implementation does seem to conflict with other uses of
Hi Roman,
I assume JVMTI maintains separate tagging data for each agent so having
two agents doing tagging won't result in confusion. I didn't actually
find this in the spec. Would be nice to confirm that it is the case.
However, your implementation does seem to conflict with other uses of
ta
On 3/20/20 8:30 AM, Roman Kennke wrote:
I believe I came up with a much simpler solution that also solves the
problems of the existing one, and the ones I proposed earlier.
It turns out that we can take advantage of the fact that we can use
*anything* as tags in JVMTI, even pointers to stuff (th
I believe I came up with a much simpler solution that also solves the
problems of the existing one, and the ones I proposed earlier.
It turns out that we can take advantage of the fact that we can use
*anything* as tags in JVMTI, even pointers to stuff (this is explicitely
mentioned in the JVMTI s
Hi Serguei,
Thanks for your review! A quick update on my progress:
The wrong condition was a good find! In-fact so much that it lead to the
whole implementation not reporting any unloaded classes. I changed that
back, and now it's so slow because of all those unloaded classes firing
events, I'm t
Sorry, forgot to complete my comments
at the end (see below).
On 3/15/20 23:57, serguei.spit...@oracle.com wrote:
Hi Roman,
Thank you for the update and sorry for the latency in review.
Some comments are below.
Hi Roman,
Thank you for the update and sorry for the latency in review.
Some comments are below.
http://cr.openjdk.java.net/~rkennke/JDK-8227269/webrev.05/src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c.frames.html
87 cbTrackingObjectF
I'll have a look at it, although it might not be for a couple of days.
Chris
On 3/9/20 5:39 AM, Roman Kennke wrote:
Hello all,
Can I please get reviews of this change? In the meantime, we've done
more testing and also field-/torture-testing by a customer who is happy
now. :-)
Thanks,
Roman
Hello all,
Can I please get reviews of this change? In the meantime, we've done
more testing and also field-/torture-testing by a customer who is happy
now. :-)
Thanks,
Roman
> Hi Serguei,
>
> Thanks for reviewing!
>
> I updated the patch to reflect your suggestions, very good!
> It also incl
Hi Serguei,
Thanks for reviewing!
I updated the patch to reflect your suggestions, very good!
It also includes a fix to allow re-connecting an agent after disconnect,
namely move setup of the trackingEnv and deletedSignatureBag to
_activate() to ensure have those structures after re-connect.
htt
Hi Roman,
Thank you for taking care about this scalability issue!
I have a couple of quick comments.
http://cr.openjdk.java.net/~rkennke/JDK-8227269/webrev.04/src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c.frames.html
72 /*
73 * Lock to p
Here comes an update that resolves some races that happen when
disconnecting an agent. In particular, we need to take the lock on
basically every operation, and also need to check whether or not
class-tracking is active and return an appropriate result (e.g. an empty
list) when we're not.
Updated
So, here comes the O(1) implementation:
- Whenever a class is 'prepared', it is registered with a tag, and we
set-up a listener to get notified when it is unloaded.
- Prepared classes are kept in a datastructure that is a table, which
each entry being the head of a linked-list of KlassNode*. The t
Hi Coleen,
>>> I'll have a look at this, although it might not be for a few days. In
>>> the meantime, maybe you can describe your new implementation in
>>> classTrack.c so it's easier to look through the changes.
>> Sure.
>>
>> The purpose of this class-tracking is to be able to determine the
>>
On 12/19/19 5:45 AM, Roman Kennke wrote:
Hi Chris,
I'll have a look at this, although it might not be for a few days. In
the meantime, maybe you can describe your new implementation in
classTrack.c so it's easier to look through the changes.
Sure.
The purpose of this class-tracking is to b
Alright, the perfectionist in me got me. I am implementing the even more
efficient ~O(1) class tracking. Please hold off reviewing for now.
Thanks,Roman
Hi Chris,
>
>> I'll have a look at this, although it might not be for a few days. In
>> the meantime, maybe you can describe your new implemen
Hi Chris,
> I'll have a look at this, although it might not be for a few days. In
> the meantime, maybe you can describe your new implementation in
> classTrack.c so it's easier to look through the changes.
Sure.
The purpose of this class-tracking is to be able to determine the
signatures of unl
Hi Roman,
I'll have a look at this, although it might not be for a few days. In
the meantime, maybe you can describe your new implementation in
classTrack.c so it's easier to look through the changes.
thanks,
Chris
On 12/18/19 5:05 AM, Roman Kennke wrote:
Hello all,
Issue:
https://bugs.op
Hello all,
Issue:
https://bugs.openjdk.java.net/browse/JDK-8227269
I am proposing what amounts to a rewrite of classTrack.c. It avoids
throwing away the class cache on GC, and instead keeps track of
loaded/unloaded classes one-by-one.
In addition to that, it avoids this whole dance until an
I filed https://bugs.openjdk.java.net/browse/JDK-8227269.
Not sure that we could fix that ourselves.
Egor
On 21-Jun-19 21:50, Chris Plummer wrote:
You might also want to have a look at:
JDK:8214892: Delayed starting of debugging via jcmd
This should allow you to defer initialization of the de
You might also want to have a look at:
JDK:8214892: Delayed starting of debugging via jcmd
This should allow you to defer initialization of the debug agent
(and the creation of the loaded classes cache) until you turn on
debugging using the jcmd (and
Will have a look, thanks for advices!
On 21-Jun-19 00:42, Chris Plummer wrote:
With respect to the specific issue brought up in
https://youtrack.jetbrains.com/issue/JBR-1611:
"If we look into the code, we'll see that whenever a new class is
loaded and an event about it is delivered, when a ga
With respect to the specific issue
brought up in https://youtrack.jetbrains.com/issue/JBR-1611:
"If we look into the code, we'll see that whenever a new class is
loaded and an event about it is delivered, when a garbage
collection has occurred, classTrack_p
Hi Egor,
yes, I‘d say this is something well known. The reason for this is that a
debugging agent will request some JVMTI capabilities like
"can_access_local_variables" which can only be requested at JVM startup.
However, once these capabilities have been taken, certain kinds of
optimizations like
Hi everyone!
we have detected that a process started with the debug agent (even when
debugger is not actually attached) may run significantly slower than
without the agent, see:
https://youtrack.jetbrains.com/issue/JBR-1611
We all thought that without the debugger attached there should not be
44 matches
Mail list logo
