Do you know, is there any other way except Cleaner and finalize() to
clean up the allocated resources?
I'm not very sure of the use of static Cleaner:
1. a daemon thread will run underlying.
2. the number of registered actions could be huge in some circumstances.
I'm not very sure if it could be a scalability bottleneck or not.
Xuelei
On 11/26/2018 5:33 PM, Weijun Wang wrote:
Ping again
On Nov 20, 2018, at 5:33 PM, Weijun Wang <weijun.w...@oracle.com> wrote:
Webrev updated at
https://cr.openjdk.java.net/~weijun/8210476/webrev.01/
The only change is that there is a single Cleaner now for the whole PRNG class.
Otherwise, each will maintain its own thread.
Thanks
Max
On Nov 11, 2018, at 11:30 PM, Weijun Wang <weijun.w...@oracle.com> wrote:
Please take a review at
https://cr.openjdk.java.net/~weijun/8210476/webrev.00/
Before this fix, every PRNG::nextBytes calls all of CryptAcquireContext,
CryptGenRandom, and CryptReleaseContext. Now, CryptAcquireContext is called
once in PRNG::new, and CryptReleaseContext is called by a Cleaner, and
nextBytes only calls CryptGenRandom.
I haven't read about thread-safety in any MS document, the current Windows-PRNG
service is marked ThreadSafe=true (in SunMSCAPI.java). If we cannot be really
sure, we can change it to false.
I've downloaded nearly 1000 Mach5 runs of this test, the enhancement is so good
that I adjusted the test to be stricter.
Before After
------ -----
Count 897 74
Min 0.38 0.008
Ave 0.97 0.011
Max 5.81 0.021
Please advise me if the following usage of Cleaner is correct because I really
haven't observed the releaseContext method being called.
+ Cleaner.create().register(this,
+ () -> releaseContext(ctxt));
Thanks
Max
