Optimize Secure Message length #777
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Instead of immediately returning from this function, previously allocated resources need to be freed first. Also, use "goto err" just for the sake of error handling consistency.
JavaThemis has the same issue as GoThemis and ThemisPP had: it disregards the real size of Secure Message output as reported by the second call to themis_secure_message_...() functions. The first call will only report an upper bound to the output length, not the actual length--which is only know after processing. Unfortunately, JVM arrays cannot be resized after they are allocated and JavaThemis API returns plain arrays. Hence, in order for the array to have correct size, we need to buffer Themis output in the native code before allocating a JVM array. This has a side effect of adding more allocations to the happy path: previously, if you were lucky, Themis Core could write directly into JVM heap and no copying or reallocation would have taked place. Now JNI code always allocates a temporary buffer and makes a copy of it. (Another minor side effect is that in case of a failure JNI code no longer allocates a JVM array beforehand, slightly relieving the GC pressure.)
777 GET!
Port the test for overlong Secure Message signatures from GoThemis and ThemisPP into Java land. Just to make sure.
vixentael
approved these changes
Feb 11, 2021
| goto err; | ||
| } | ||
|
|
||
| output_bytes = (*env)->GetPrimitiveArrayCritical(env, output, NULL); |
There was a problem hiding this comment.
so we pause garbage collectors here, moves bytes from output_buffer to output_bytes, and un-pause garbage collectors, right?
i followed description of GetPrimitiveArrayCritical at SO.
There was a problem hiding this comment.
so we pause garbage collectors here, moves bytes from output_buffer to output_bytes, and un-pause garbage collectors, right?
Basically yeah. Either pause to synchronize access, or making a copy and synchronizing copying it back.
This may or may not have an effect on the overall system. I'm sure there are effects to using both critical and non-critical variants, but I'm not an expert on Dalvik or other JVMs so have no clue on how strong those effects can be.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Following #775, make the same changes to JavaThemis to slightly reduce the length of Secure Message signatures. At a cost, though.
JavaThemis has the same issue as GoThemis and ThemisPP had: it disregards the real size of Secure Message output as reported by the second call to
themis_secure_message_...()functions. The first call will only report an upper bound to the output length, not the actual length—which is only know after processing.Unfortunately, JVM arrays cannot be resized after they are allocated and JavaThemis API returns plain arrays. Hence, in order for the array to have correct size, we need to buffer Themis output in the native code before allocating a JVM array.
This has a side effect of adding more allocations to the happy path: previously, if you were lucky, Themis Core could write directly into JVM heap and no copying or reallocation would have taken place. Now JNI code always allocates a temporary buffer and makes a copy of it.
(Another minor side effect is that in case of a failure JNI code no longer allocates a JVM array beforehand, slightly relieving the GC pressure.)
Checklist
Benchmark results are attached