P3 Description
In a email exchange with Lois we agreed to separate this issue from the
ana milestone issue:
https://bugs.openjdk.java.net/browse/JDK-8134950
Here are the concern from Lois and my reply:
Hi Lois,
Thank you for sharing your concern!
I was thinking about this too.
It is true that the JvmtiExport::add_default_read_edges() can go over a safepoint.
But it is not only a problem.
I'm afraid, holding the module_lock will add undesired dependency among
loading of classes from the same module and that can potentially cause deadlocks.
It will also interfere with the acts of class redefinitions/retransformations.
The default read edges in the thread #2 are needed only when the
instrumented code is really executed, for instance, makes calls to
methods from one of the unnamed modules.
Now, the exception will be thrown at the unnamed module resolution time.
One possible solution would be to add checks at that points and wait for the
JvmtiExport::add_default_read_edges() completion if necessary.
I still have some doubt if this kind of complexity is worth to add.
Current webrev is to avoid the recursive call to the JvmtiExport::add_default_read_edges().
What about to file another bug for your concern and so, separate it from current bug?
We can target to fix it in the milestone Bill.
Thanks,
Serguei
On 10/13/15 07:12, Lois Foltan wrote:
>
> On 10/12/2015 6:11 PM, serguei.spitsyn@oracle.com wrote:
>> Hi Lois and Alan,
>>
>> Below is the webrev with resolved review comments.
>> Do you have any concerns?
>
> Hi Serguei,
>
> Thank you for making the change, however, I do still have some concerns. Ideally the setting of the read edges, via the call to JvmtiExport::add_default_read_edges(), should be under a lock. You could have thread #1 that has "won the potential race" and after releasing the lock goes to set the read edges, while thread #2 looses the race and assumes it can use those read edges prior to thread #1 finishing the set up. However, you can't call into java while holding a lock, so I am not overly familiar with the right solution here. Is there a way to block everyone, establish the read edges via call into java, then unblock? We may have to consult with Karen on this.
>
> Thanks,
> Lois
ana milestone issue:
https://bugs.openjdk.java.net/browse/JDK-8134950
Here are the concern from Lois and my reply:
Hi Lois,
Thank you for sharing your concern!
I was thinking about this too.
It is true that the JvmtiExport::add_default_read_edges() can go over a safepoint.
But it is not only a problem.
I'm afraid, holding the module_lock will add undesired dependency among
loading of classes from the same module and that can potentially cause deadlocks.
It will also interfere with the acts of class redefinitions/retransformations.
The default read edges in the thread #2 are needed only when the
instrumented code is really executed, for instance, makes calls to
methods from one of the unnamed modules.
Now, the exception will be thrown at the unnamed module resolution time.
One possible solution would be to add checks at that points and wait for the
JvmtiExport::add_default_read_edges() completion if necessary.
I still have some doubt if this kind of complexity is worth to add.
Current webrev is to avoid the recursive call to the JvmtiExport::add_default_read_edges().
What about to file another bug for your concern and so, separate it from current bug?
We can target to fix it in the milestone Bill.
Thanks,
Serguei
On 10/13/15 07:12, Lois Foltan wrote:
>
> On 10/12/2015 6:11 PM, serguei.spitsyn@oracle.com wrote:
>> Hi Lois and Alan,
>>
>> Below is the webrev with resolved review comments.
>> Do you have any concerns?
>
> Hi Serguei,
>
> Thank you for making the change, however, I do still have some concerns. Ideally the setting of the read edges, via the call to JvmtiExport::add_default_read_edges(), should be under a lock. You could have thread #1 that has "won the potential race" and after releasing the lock goes to set the read edges, while thread #2 looses the race and assumes it can use those read edges prior to thread #1 finishing the set up. However, you can't call into java while holding a lock, so I am not overly familiar with the right solution here. Is there a way to block everyone, establish the read edges via call into java, then unblock? We may have to consult with Karen on this.
>
> Thanks,
> Lois