Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8139566

need proper sync for adding default read edges



    • Subcomponent:
    • Resolved In Build:
    • CPU:
    • OS:


      In a email exchange with Lois we agreed to separate this issue from the
      ana milestone issue:

      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.


      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




            sspitsyn Serguei Spitsyn
            sspitsyn Serguei Spitsyn
            0 Vote for this issue
            5 Start watching this issue