Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2220964 | 8 | Tom Rodriguez | P2 | Closed | Fixed | b25 |
JDK-2220859 | 7u4 | Tom Rodriguez | P2 | Closed | Fixed | b11 |
While those java memory management issues may have improved, the reality is that we need to have a quicker and more direct way to get to the OS libraries. It is the hope that by having a more direct access to the library, that we can eliminate some of the memory and other java calls that are needed use JNI and leave that work to the OS library were it's faster. The quicker access also allows us to get better performance from smaller byte sizes of crypto/message digest operations.
This is of particular importance for the new crypto hardware acceleration in T4 and the availability of the libsoftcrypto/libmd libaries that allow quick, lightweight access. This combination could be a great perfomance improvement for Solaris/SPARC, potentically record numbers (?).
- backported by
-
JDK-2220859 allow crypto functions to be called inline to enhance performance
- Closed
-
JDK-2220964 allow crypto functions to be called inline to enhance performance
- Closed
- relates to
-
JDK-8191360 Lookup of critical JNI method causes duplicate library loading with leaking handler
- Resolved
-
JDK-8167408 Invalid critical JNI function lookup
- Resolved
-
JDK-7145024 Crashes in ucrypto related to C2
- Closed
-
JDK-7144405 JumbleGC002 assert(m->offset() == pc_offset) failed: oopmap not found
- Closed
-
JDK-7150051 incorrect oopmap in critical native
- Closed
-
JDK-7088989 Improve the performance for T4 by utilizing the newly provided crypto APIs
- Closed
-
JDK-8233343 Deprecate -XX:+CriticalJNINatives flag which implements JavaCritical native functions
- Resolved