You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
| org.bouncycastle.native.cpu_variant | avx, vaes, vaesf or neon-le | Specify a variant to use see "Selecting a specific variant" for warnings. |
234
+
| org.bouncycastle.packet_cipher_enabled | true or false | False by default, enable or disable use of packet ciphers where appropriate. |
235
+
| org.bouncycastle.native.cleanup_delay | 1000ms / 1 | Delays freeing of native allocations by the given time in milliseconds or seconds, the default is 0. |
236
+
237
+
238
+
### Disposal Daemon / Freeing native allocations
239
+
The library tacks classes and when they become available for garbage collection, and we free any underlying native allocations.
240
+
241
+
Overly aggressive garbage collectors may signal that a class is available for collection while another thread is accessing
242
+
that class. On busy multicore machines this may occur during the last call to that class causing use after free situation.
243
+
244
+
To deal with this we have employed either the reachability fence, applicable on java 9 and above or synchronized blocks for
245
+
java 8.
246
+
247
+
If this proves to be unreliable users can also set a cleanup delay via the ```org.bouncycastle.native.cleanup_delay``` property.
248
+
For example:
249
+
250
+
```-Dorg.bouncycastle.native.cleanup_delay=10ms``` would set a delay of 10 milliseconds, and
251
+
```-Dorg.bouncycastle.native.cleanup_delay=1``` would set a delay of 1 second.
252
+
253
+
The default cleanup delay is zero and native allocations will be cleaned up immediately upon notification that the relevant
0 commit comments