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

need proper sync for adding default read edges

    XMLWordPrintable

    Details

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

      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

        Attachments

          Activity

            People

            Assignee:
            sspitsyn Serguei Spitsyn
            Reporter:
            sspitsyn Serguei Spitsyn
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Dates

              Due:
              Created:
              Updated:
              Resolved: