<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    On 11/1/18 1:45 PM, Mandy Chung wrote:<br>
    <blockquote type="cite"
      cite="mid:ebbd38f4-d10c-b986-d0d1-86581cc16c56@oracle.com">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <br>
      <br>
      <div class="moz-cite-prefix">On 11/1/18 1:18 AM, Vladimir Ivanov
        wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:43be67e3-c6a5-3ad2-d835-e9c32f90374f@oracle.com"> <br>
        <blockquote type="cite">I think it's a good idea, but I believe
          it would require a CSR request. Do you mind if I file a
          separate issue for jdk.internal.vm.annotation.Hidden? <br>
        </blockquote>
        <br>
        Sure. <br>
        <br>
        Most of the annotations in jdk.internal.vm.annotation were
        originally located in java.lang.invoke. Not sure CSR will be
        required in this particular case. <br>
        <br>
      </blockquote>
      <br>
      @Hidden is internal and no CSR is needed.<br>
      <br>
      FYI.  JDK-8212620 is the RFE to consider providing a standard
      mechanism to hide frames from stack trace.<br>
      <br>
    </blockquote>
    <br>
    OK, I already filed JDK-8213234 but I think I should just close it
    as a duplicate of JDK-8212620.<br>
    <br>
    dl<br>
    <br>
    <blockquote type="cite"
      cite="mid:ebbd38f4-d10c-b986-d0d1-86581cc16c56@oracle.com"> Mandy<br>
      <br>
      <blockquote type="cite"
        cite="mid:43be67e3-c6a5-3ad2-d835-e9c32f90374f@oracle.com">Best
        regards, <br>
        Vladimir Ivanov <br>
        <br>
        <blockquote type="cite">On 10/31/18 6:11 PM, Vladimir Ivanov
          wrote: <br>
          <blockquote type="cite">Dean, <br>
            <br>
src/java.base/share/classes/java/security/AccessController.java: <br>
            +    /** <br>
            +     * Internal marker for hidden implementation frames. <br>
            +     */ <br>
            +    /*non-public*/ <br>
            +    @Target(ElementType.METHOD) <br>
            +    @Retention(RetentionPolicy.RUNTIME) <br>
            +    @interface Hidden { <br>
            +    } <br>
            <br>
            You declare @Hidden, but then map it to _method_Hidden along
            with @Hidden from java.lang.invoke.LambdaForm. <br>
            <br>
            What do you think about moving LambdaForm.Hidden to
            jdk.internal.vm.annotation instead and share among all
            usages? <br>
            <br>
            Best regards, <br>
            Vladimir Ivanov <br>
            <br>
            On 31/10/2018 15:23, <a class="moz-txt-link-abbreviated"
              href="mailto:dean.long@oracle.com" moz-do-not-send="true">dean.long@oracle.com</a>
            wrote: <br>
            <blockquote type="cite"><a class="moz-txt-link-freetext"
                href="https://bugs.openjdk.java.net/browse/JDK-8212605"
                moz-do-not-send="true">https://bugs.openjdk.java.net/browse/JDK-8212605</a>
              <br>
              <a class="moz-txt-link-freetext"
                href="http://cr.openjdk.java.net/%7Edlong/8212605/webrev.1"
                moz-do-not-send="true">http://cr.openjdk.java.net/~dlong/8212605/webrev.1</a>
              <br>
              <br>
              This change implements AccessController.doPrivileged in
              Java. This gives a performance improvement while also
              being useful to Project Loom by removing the Java -->
              native --> Java transition.  One reason doPrivileged
              has historically been in native is because of the need to
              guarantee the cleanup of the privileged context when
              doPrivileged returns.  To do that in Java, the information
              that AccessController.getContext needs is pushed onto the
              Java stack as arguments to a method that getContext will
              recognize during its stack walk.  This allows us to remove
              the native privileged stack while guaranteeing that the
              privileged context goes away when the method returns. <br>
              <br>
              Tested with tier1-tier3 hotspot and jdk tests and JCK
              api/java_security tests.  For the first few rounds of
              testing, I kept the old native privileged stack and
              compared the results of the old and new implementations
              for each getContext call, which did catch some early
              bugs.  The changes were also examined by internal security
              experts and run through additional internal security
              tests. <br>
              <br>
              The improvement on this [1] doPrivileged microbenchmark is
              approximate 50x. <br>
              <br>
              There is no attempt to optimize getContext() or security
              permission checks in this change, however, this is
              intended to be a first step towards other possible
              improvements, for example those proposed here [2]. <br>
              <br>
              dl <br>
              <br>
              [1]
              <a class="moz-txt-link-freetext"
href="http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java"
                moz-do-not-send="true">http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java</a>
              <br>
              [2]
              <a class="moz-txt-link-freetext"
href="http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html"
                moz-do-not-send="true">http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html</a>
              <br>
              <br>
            </blockquote>
          </blockquote>
          <br>
        </blockquote>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>