Add Java-side cache with large-request bypass for native RNG#1221
Add Java-side cache with large-request bypass for native RNG#1221
Conversation
Introduce a Java-side cache to reduce native RNG calls for small and medium SecureRandom requests. Previously, each nextBytes() call delegated directly to the native RNG, causing frequent calls and extra overhead for workloads that repeatedly request small buffers. With this change: • A large cache is filled from the native RNG and serves small and medium requests, reducing native invocations. • Large requests bypass the cache and are filled directly from the native RNG to avoid extra copy overhead. • After a bypass, the cache is invalidated so later small requests will refill from fresh native call. Signed-off-by: Tao Liu <tao.liu@ibm.com>
taoliult
requested review from
JinhangZhang,
KostasTsiounis,
jasonkatonica and
johnpeck-us-ibm
|
The code looks okay for what it is meant to do. However, this could be a security issue. What is the use case here that we are trying to resolve? |
| final long ockPRNGContextId; | ||
|
|
||
| // 128KB cache ? | ||
| private static final int MEGABYTE_CACHE_SIZE = 128 * 1024; |
There was a problem hiding this comment.
Can this be a configurable size. By default one megabyte seems reasonable to me given your findings.
| private static final int MEGABYTE_CACHE_SIZE = 128 * 1024; | ||
|
|
||
| // 16KB threshold ? | ||
| private static final int BYPASS_THRESHOLD = 16 * 1024; |
There was a problem hiding this comment.
What is the threshold trying to accomplish? Seems like if the user wants more randoms then is in the cache then we would then make a trip to the native layer to fill the cache at that time and then return the bytes to the caller. This would save some complexity for now.
| @@ -16,6 +16,16 @@ public final class ExtendedRandom { | |||
| OCKContext ockContext; | |||
There was a problem hiding this comment.
Do we need any additional testing in our test buckets to test randoms from the cache right around the boundary limits for our cache?
3 participants
Introduce a Java-side cache to reduce native RNG calls for small and medium SecureRandom requests.
Previously, each nextBytes() call delegated directly to the native RNG, causing frequent calls and extra overhead for workloads that repeatedly request small buffers.
With this change:
• A large cache is filled from the native RNG and serves small and medium requests, reducing native invocations.
• Large requests bypass the cache and are filled directly from the native RNG to avoid extra copy overhead.
• After a bypass, the cache is invalidated so later small requests will refill from fresh native call.