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

SecureRandom.nextBytes() hurts performance with small size requests

    Details

      Backports

        Description

        Server threads were shown to be blocked and timeout during PAE testing. This showed up more in smaller heap sizes. Pulling many bytes and buffering would help this.

        java.lang.Thread.State: BLOCKED (on object monitor)
        at java.security.SecureRandom.nextBytes(SecureRandom.java:457)
        - waiting to lock <0x00000007a256cc20> (a java.security.SecureRandom)
        at sun.security.util.KeyUtil.checkTlsPreMasterSecretKey(KeyUtil.java:205)
        at com.sun.crypto.provider.RSACipher.engineUnwrap(RSACipher.java:459)
        at javax.crypto.Cipher.unwrap(Cipher.java:2506)
        at sun.security.ssl.RSAClientKeyExchange.<init>(RSAClientKeyExchange.java:120)
        at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:238)

        java.lang.Thread.State: RUNNABLE
        at java.io.FileInputStream.readBytes(Native Method)
        at java.io.FileInputStream.read(FileInputStream.java:255)
        at sun.security.provider.NativePRNG$RandomIO.readFully(NativePRNG.java:410)
        at sun.security.provider.NativePRNG$RandomIO.ensureBufferValid(NativePRNG.java:473)
        at sun.security.provider.NativePRNG$RandomIO.implNextBytes(NativePRNG.java:487)
        - locked <0x00000007a08a8ec0> (a java.lang.Object)
        at sun.security.provider.NativePRNG$RandomIO.access$400(NativePRNG.java:329)
        at sun.security.provider.NativePRNG.engineNextBytes(NativePRNG.java:218)
        at java.security.SecureRandom.nextBytes(SecureRandom.java:457)
        - locked <0x00000007a256cc20> (a java.security.SecureRandom)
        at sun.security.ssl.CipherBox.createExplicitNonce(CipherBox.java:1015)

          Issue Links

            Activity

            Hide
            twen Tony Wen added a comment -
            Anthony, thanks for your quick reply. I can understand what you side about the big buffer size. But, I found the same code works well on Windows. The difference is the algorithm implementation. On Windows, it's "securerandom.strongAlgorithms=Windows-PRNG:SunMSCAPI,SHA1PRNG:SUN", while on Linux is "securerandom.strongAlgorithms=NativePRNGNonBlocking:SUN". I'm not familiar about these algorithms. It seems they are both provided by us(Oracle/SUN). Why do they perform this different? Is there any Linux OS level reason that makes the implementation on Linux cannot performance well like the implementation on Windows? Please forgive me if I asked a silly question.
            Show
            twen Tony Wen added a comment - Anthony, thanks for your quick reply. I can understand what you side about the big buffer size. But, I found the same code works well on Windows. The difference is the algorithm implementation. On Windows, it's "securerandom.strongAlgorithms=Windows-PRNG:SunMSCAPI,SHA1PRNG:SUN", while on Linux is "securerandom.strongAlgorithms=NativePRNGNonBlocking:SUN". I'm not familiar about these algorithms. It seems they are both provided by us(Oracle/SUN). Why do they perform this different? Is there any Linux OS level reason that makes the implementation on Linux cannot performance well like the implementation on Windows? Please forgive me if I asked a silly question.
            Hide
            ascarpino Anthony Scarpino added a comment -
            I have heard in the past that Linux was slow on generating random numbers, but I have never experienced it. Since the thread is stuck on FileInputStream.readBytes() my first guess would be the OS.

            Windows is using a different random number implementation, and I do not know the quality of Microsoft's random number generator. I would assume it's ok. Solaris or Mac OS I believe use the same implementation, NativePRNG. If Solaris and MacOS both were slow, then it might point to something in the NativePRNG implementation.
            Show
            ascarpino Anthony Scarpino added a comment - I have heard in the past that Linux was slow on generating random numbers, but I have never experienced it. Since the thread is stuck on FileInputStream.readBytes() my first guess would be the OS. Windows is using a different random number implementation, and I do not know the quality of Microsoft's random number generator. I would assume it's ok. Solaris or Mac OS I believe use the same implementation, NativePRNG. If Solaris and MacOS both were slow, then it might point to something in the NativePRNG implementation.
            Hide
            twen Tony Wen added a comment -
            Anthony, thanks for help. I've tested the code on Linux and Mac OS. It only happens on Linux. So, most likely this is an OS level problem.
            Show
            twen Tony Wen added a comment - Anthony, thanks for help. I've tested the code on Linux and Mac OS. It only happens on Linux. So, most likely this is an OS level problem.
            Hide
            coffeys Sean Coffey added a comment -
            in response to Tony Wen's updates : Lack of entropy in linux can be problematic in such cases. E.g. https://major.io/2007/07/01/check-available-entropy-in-linux/
            Show
            coffeys Sean Coffey added a comment - in response to Tony Wen's updates : Lack of entropy in linux can be problematic in such cases. E.g. https://major.io/2007/07/01/check-available-entropy-in-linux/
            Hide
            twen Tony Wen added a comment -
            [~coffeys] Thanks for your information. I'm not sure how this entropy works. But, it seems it's not the reason for this problem. As the article suggested, I've checked the available entropy value. It's 133 which is between the suggested 100-200.
            Show
            twen Tony Wen added a comment - [~coffeys] Thanks for your information. I'm not sure how this entropy works. But, it seems it's not the reason for this problem. As the article suggested, I've checked the available entropy value. It's 133 which is between the suggested 100-200.

              People

              • Assignee:
                ascarpino Anthony Scarpino
                Reporter:
                ascarpino Anthony Scarpino
              • Votes:
                0 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: