NativeDigest context free via Cleaner API

[alon-sh]

due to issues such as eclipse-openj9/openj9#5611 removed the native context de-allocation via a finalizer. Introduced the use of PhantomReferences to control when the native digest context can be de-allocated.

The cleanup stage happens when the reference array is fully used, at which point there is an attempted clean-up by examining the ReferenceQueue which will de-allocate the native contexts and also free up space in the reference array.

Signed-off-by: Alon Shalev Housfater alonsh@ca.ibm.com

[alon-sh]

@pshipton @DanHeidinga @keithc-ca still testing the changes locally. If possible, would like to get the review cycle started. See eclipse-openj9/openj9#5611 and eclipse-openj9/openj9#4530 for the actual error reports.

Also note that I can't be certain this PR will fix those issues as I'm unable to reproduce the error locally. However, looking at the code at Java_jdk_crypto_jniprovider_NativeCrypto_DigestUpdate which has extensive error checking likely the crash occurs here:
(*OSSL_DigestUpdate)(context->ctx, (messageNative + messageOffset), messageLen)

so I'm assuming context is de-allocated too early which is why the crash happens in the finalizer of sun/security/ssl/BaseSSLSocketImpl

[pshipton]

This won't clean if new Digest's aren't being created. Ideally https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/Cleaner.html should be used.

[keithc-ca]

You may want to reuse the common cleaner accessible via jdk.internal.ref.CleanerFactory.cleaner().

[alon-sh]

@pshipton @keithc-ca is this also available for jdk8?

[keithc-ca]

Yes, in Java 8 there is sun.misc.Cleaner (with differing API).

[DanHeidinga]

@ashbm5 Are you adapting this PR in light of Keith & Peter's comments on using sun.misc.Cleaner?

[alon-sh]

@DanHeidinga I'm a bit concerned about the performance impact of using sun.misc.Cleaner since it requires a background thread so I'm also evaluating the perf. impact of this approach. Also try different ways of resolving this issue - perhaps by buffering input data before sending to OpenSSL

[DanHeidinga]

Look at how Cleaner is used in other places. MutableCallSite is one example:
https://github.com/eclipse/openj9/blob/5d28821b3de3e0b01d0d9eaf2a8159628f819d0a/jcl/src/java.base/share/classes/java/lang/invoke/MutableCallSite.java#L84-L85

https://github.com/eclipse/openj9/blob/5d28821b3de3e0b01d0d9eaf2a8159628f819d0a/jcl/src/java.base/share/classes/java/lang/invoke/MutableCallSite.java#L294-L308

The Cleaner is processed immediately when it's being enqueued. No extra thread is required.

[alon-sh]

@pshipton @keithc-ca @DanHeidinga updated the PR with using the Cleaner API code. I did the relevant performance testing and found out that there is some impact when constant digest objects are being created and released when compared to finalizer but only slightly so while hopefully fixing the reported issues. with optimized code that doesn't constantly create new digest objects, there is no performance impact.

[alon-sh]

@keithc-ca updated, please review

[keithc-ca]

Please address the merge conflict. Please also rebase (on the current head of the openj9 branch) and squash.

[alon-sh]

@keithc-ca updated, please review

[keithc-ca]

Jenkins test all,sanity,extended zlinux jdk11

[keithc-ca]

The build and both test jobs were successful, but something strange happened to the 'parallel' part of the test job: merging under the assumption that the strangeness is irrelevant.