Added an "unsafe" way to retrieve a byte array from SdkBytes and ResponseBytes without copying the data.
#1977
Conversation
This file contains hidden or 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
Codecov Report
@@ Coverage Diff @@
## master #1977 +/- ##
============================================
- Coverage 76.63% 76.63% -0.01%
Complexity 225 225
============================================
Files 1112 1112
Lines 33653 33660 +7
Branches 2621 2606 -15
============================================
+ Hits 25791 25795 +4
- Misses 6584 6587 +3
Partials 1278 1278
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
millems
force-pushed
the
millem/less-copying
branch
from
c621f10 to
bf22a05
Compare
|
Integration tests have passed. Running benchmarks... |
|
Unit tests have passed. Still waiting on benchmarks... |
|
No appreciable difference in benchmarks. |
zoewangg
reviewed
Aug 11, 2020
core/sdk-core/src/test/java/software/amazon/awssdk/core/ResponseBytesTest.java
Show resolved
Hide resolved
…esponseBytes` without copying the data.
millems
force-pushed
the
millem/less-copying
branch
from
55eff4f to
c6bebf9
Compare
zoewangg
approved these changes
Aug 12, 2020
|
SonarCloud Quality Gate failed.
|
aws-sdk-java-automation
added a commit
that referenced
this pull request
Mar 31, 2022
…3a81bcb60 Pull request: release <- staging/11492aef-de88-4dde-99d1-db93a81bcb60
rtyley
added a commit
to rtyley/aws-sdk-async-response-bytes
that referenced
this pull request
Aug 26, 2023
Once the `ByteArrayAsyncResponseTransformer` has gathered all the response bytes, we still need to wrap those bytes and the response object in a `ResponseBytes` instance - but if we use `ResponseBytes.fromByteArray()`, a whole new byte array will be allocated, which is bad for two reasons: * While copying, the JVM heap must briefly hold both the old & new byte arrays - roughly speaking, doubling the memory requirements. * Copying the bytes from one array to another takes a little bit of CPU time (obviously this varies: `System.arraycopy()` for 40MB of bytes takes ~2ms on my M1 machine). A faster, more memory efficient alternative to `ResponseBytes.fromByteArray()` is `ResponseBytes.fromByteArrayUnsafe()`, added to the AWS SDK in August 2020 with aws/aws-sdk-java-v2#1977 in response to aws/aws-sdk-java-v2#1959. The 'Unsafe' in the name is a warning to users of this method that the underlying byte array is _not_ copied, and so could be susceptible to badly-behaving code manipulating the contents of the byte array after the `ResponseBytes` is handed to the calling code. If only the trusted SDK code has access to the original byte array before `ResponseBytes` is handed over to the caller, and once the `ResponseBytes` instance is handed over to the caller, the SDK code has no further use for the original byte array, then it is safe to use `ResponseBytes.fromByteArrayUnsafe()` in the trusted SDK code, and return the resulting `ResponseBytes` to the user, saving a double-allocation of memory, and the CPU time for the copying of bytes. See also: * aws/aws-sdk-java-v2#1959 * aws/aws-sdk-java-v2#1977
rtyley
added a commit
to rtyley/aws-sdk-async-response-bytes
that referenced
this pull request
Aug 26, 2023
Once the `ByteArrayAsyncResponseTransformer` has gathered all the response bytes, we still need to wrap those bytes and the response object in a `ResponseBytes` instance - but if we use `ResponseBytes.fromByteArray()`, a whole new byte array will be allocated, which is bad for two reasons: * While copying, the JVM heap must briefly hold both the old & new byte arrays - roughly speaking, doubling the memory requirements. * Copying the bytes from one array to another takes a little bit of CPU time (obviously this varies: `System.arraycopy()` for 40MB of bytes takes ~2ms on my M1 machine). A faster, more memory efficient alternative to `ResponseBytes.fromByteArray()` is `ResponseBytes.fromByteArrayUnsafe()`, added to the AWS SDK in August 2020 with aws/aws-sdk-java-v2#1977 in response to aws/aws-sdk-java-v2#1959. The 'Unsafe' in the name is a warning to users of this method that the underlying byte array is _not_ copied, and so could be susceptible to badly-behaving code manipulating the contents of the byte array after the `ResponseBytes` is handed to the calling code. If only the trusted SDK code has access to the original byte array before `ResponseBytes` is handed over to the caller, and once the `ResponseBytes` instance is handed over to the caller, the SDK code has no further use for the original byte array, then it is safe to use `ResponseBytes.fromByteArrayUnsafe()` in the trusted SDK code, and return the resulting `ResponseBytes` to the user, saving a double-allocation of memory, and the CPU time for the copying of bytes. See also: * aws/aws-sdk-java-v2#1959 * aws/aws-sdk-java-v2#1977
rtyley
added a commit
to rtyley/aws-sdk-async-response-bytes
that referenced
this pull request
Aug 26, 2023
Once the `ByteArrayAsyncResponseTransformer` has gathered all the response bytes, we still need to wrap those bytes and the response object in a `ResponseBytes` instance - but if we use `ResponseBytes.fromByteArray()`, a whole new byte array will be allocated, which is bad for two reasons: * While copying, the JVM heap must briefly hold both the old & new byte arrays - roughly speaking, doubling the memory requirements. * Copying the bytes from one array to another takes a little bit of CPU time (obviously this varies: `System.arraycopy()` for 40MB of bytes takes ~2ms on my M1 machine). A faster, more memory efficient alternative to `ResponseBytes.fromByteArray()` is `ResponseBytes.fromByteArrayUnsafe()`, added to the AWS SDK in August 2020 with aws/aws-sdk-java-v2#1977 in response to aws/aws-sdk-java-v2#1959. The 'Unsafe' in the name is a warning to users of this method that the underlying byte array is _not_ copied, and so could be susceptible to badly-behaving code manipulating the contents of the byte array after the `ResponseBytes` is handed to the calling code. If only the trusted SDK code has access to the original byte array before `ResponseBytes` is handed over to the caller, and once the `ResponseBytes` instance is handed over to the caller, the SDK code has no further use for the original byte array, then it is safe to use `ResponseBytes.fromByteArrayUnsafe()` in the trusted SDK code, and return the resulting `ResponseBytes` to the user, saving a double-allocation of memory, and the CPU time for the copying of bytes. See also: * aws/aws-sdk-java-v2#1959 * aws/aws-sdk-java-v2#1977
rtyley
added a commit
to rtyley/aws-sdk-async-response-bytes
that referenced
this pull request
Aug 27, 2023
Once the `ByteArrayAsyncResponseTransformer` has gathered all the response bytes, we still need to wrap those bytes and the response object in a `ResponseBytes` instance - but if we use `ResponseBytes.fromByteArray()`, a whole new byte array will be allocated, which is bad for two reasons: * While copying, the JVM heap must briefly hold both the old & new byte arrays - roughly speaking, doubling the memory requirements. * Copying the bytes from one array to another takes a little bit of CPU time (obviously this varies: `System.arraycopy()` for 40MB of bytes takes ~2ms on my M1 machine). A faster, more memory efficient alternative to `ResponseBytes.fromByteArray()` is `ResponseBytes.fromByteArrayUnsafe()`, added to the AWS SDK in August 2020 with aws/aws-sdk-java-v2#1977 in response to aws/aws-sdk-java-v2#1959. The 'Unsafe' in the name is a warning to users of this method that the underlying byte array is _not_ copied, and so could be susceptible to badly-behaving code manipulating the contents of the byte array after the `ResponseBytes` is handed to the calling code. If only the trusted SDK code has access to the original byte array before `ResponseBytes` is handed over to the caller, and once the `ResponseBytes` instance is handed over to the caller, the SDK code has no further use for the original byte array, then it is safe to use `ResponseBytes.fromByteArrayUnsafe()` in the trusted SDK code, and return the resulting `ResponseBytes` to the user, saving a double-allocation of memory, and the CPU time for the copying of bytes. See also: * aws/aws-sdk-java-v2#1959 * aws/aws-sdk-java-v2#1977
rtyley
added a commit
to rtyley/aws-sdk-async-response-bytes
that referenced
this pull request
Sep 2, 2023
Once the `ByteArrayAsyncResponseTransformer` has gathered all the response bytes, we still need to wrap those bytes and the response object in a `ResponseBytes` instance - but if we use `ResponseBytes.fromByteArray()`, a whole new byte array will be allocated, which is bad for two reasons: * While copying, the JVM heap must briefly hold both the old & new byte arrays - roughly speaking, doubling the memory requirements. * Copying the bytes from one array to another takes a little bit of CPU time (obviously this varies: `System.arraycopy()` for 40MB of bytes takes ~2ms on my M1 machine). A faster, more memory efficient alternative to `ResponseBytes.fromByteArray()` is `ResponseBytes.fromByteArrayUnsafe()`, added to the AWS SDK in August 2020 with aws/aws-sdk-java-v2#1977 in response to aws/aws-sdk-java-v2#1959. The 'Unsafe' in the name is a warning to users of this method that the underlying byte array is _not_ copied, and so could be susceptible to badly-behaving code manipulating the contents of the byte array after the `ResponseBytes` is handed to the calling code. If only the trusted SDK code has access to the original byte array before `ResponseBytes` is handed over to the caller, and once the `ResponseBytes` instance is handed over to the caller, the SDK code has no further use for the original byte array, then it is safe to use `ResponseBytes.fromByteArrayUnsafe()` in the trusted SDK code, and return the resulting `ResponseBytes` to the user, saving a double-allocation of memory, and the CPU time for the copying of bytes. See also: * aws/aws-sdk-java-v2#1959 * aws/aws-sdk-java-v2#1977
rtyley
added a commit
to rtyley/aws-sdk-async-response-bytes
that referenced
this pull request
Sep 2, 2023
Once the `ByteArrayAsyncResponseTransformer` has gathered all the response bytes, we still need to wrap those bytes and the response object in a `ResponseBytes` instance - but if we use `ResponseBytes.fromByteArray()`, a whole new byte array will be allocated, which is bad for two reasons: * While copying, the JVM heap must briefly hold both the old & new byte arrays - roughly speaking, doubling the memory requirements. * Copying the bytes from one array to another takes a little bit of CPU time (obviously this varies: `System.arraycopy()` for 40MB of bytes takes ~2ms on my M1 machine). A faster, more memory efficient alternative to `ResponseBytes.fromByteArray()` is `ResponseBytes.fromByteArrayUnsafe()`, added to the AWS SDK in August 2020 with aws/aws-sdk-java-v2#1977 in response to aws/aws-sdk-java-v2#1959. The 'Unsafe' in the name is a warning to users of this method that the underlying byte array is _not_ copied, and so could be susceptible to badly-behaving code manipulating the contents of the byte array after the `ResponseBytes` is handed to the calling code. If only the trusted SDK code has access to the original byte array before `ResponseBytes` is handed over to the caller, and once the `ResponseBytes` instance is handed over to the caller, the SDK code has no further use for the original byte array, then it is safe to use `ResponseBytes.fromByteArrayUnsafe()` in the trusted SDK code, and return the resulting `ResponseBytes` to the user, saving a double-allocation of memory, and the CPU time for the copying of bytes. See also: * aws/aws-sdk-java-v2#1959 * aws/aws-sdk-java-v2#1977
rtyley
added a commit
to rtyley/aws-sdk-async-response-bytes
that referenced
this pull request
Sep 2, 2023
Once the `ByteArrayAsyncResponseTransformer` has gathered all the response bytes, we still need to wrap those bytes and the response object in a `ResponseBytes` instance - but if we use `ResponseBytes.fromByteArray()`, a whole new byte array will be allocated, which is bad for two reasons: * While copying, the JVM heap must briefly hold both the old & new byte arrays - roughly speaking, doubling the memory requirements. * Copying the bytes from one array to another takes a little bit of CPU time (obviously this varies: `System.arraycopy()` for 40MB of bytes takes ~2ms on my M1 machine). A faster, more memory efficient alternative to `ResponseBytes.fromByteArray()` is `ResponseBytes.fromByteArrayUnsafe()`, added to the AWS SDK in August 2020 with aws/aws-sdk-java-v2#1977 in response to aws/aws-sdk-java-v2#1959. The 'Unsafe' in the name is a warning to users of this method that the underlying byte array is _not_ copied, and so could be susceptible to badly-behaving code manipulating the contents of the byte array after the `ResponseBytes` is handed to the calling code. If only the trusted SDK code has access to the original byte array before `ResponseBytes` is handed over to the caller, and once the `ResponseBytes` instance is handed over to the caller, the SDK code has no further use for the original byte array, then it is safe to use `ResponseBytes.fromByteArrayUnsafe()` in the trusted SDK code, and return the resulting `ResponseBytes` to the user, saving a double-allocation of memory, and the CPU time for the copying of bytes. See also: * aws/aws-sdk-java-v2#1959 * aws/aws-sdk-java-v2#1977
rtyley
added a commit
to rtyley/aws-sdk-async-response-bytes
that referenced
this pull request
Sep 2, 2023
Once the `ByteArrayAsyncResponseTransformer` has gathered all the response bytes, we still need to wrap those bytes and the response object in a `ResponseBytes` instance - but if we use `ResponseBytes.fromByteArray()`, a whole new byte array will be allocated, which is bad for two reasons: * While copying, the JVM heap must briefly hold both the old & new byte arrays - roughly speaking, doubling the memory requirements. * Copying the bytes from one array to another takes a little bit of CPU time (obviously this varies: `System.arraycopy()` for 40MB of bytes takes ~2ms on my M1 machine). A faster, more memory efficient alternative to `ResponseBytes.fromByteArray()` is `ResponseBytes.fromByteArrayUnsafe()`, added to the AWS SDK in August 2020 with aws/aws-sdk-java-v2#1977 in response to aws/aws-sdk-java-v2#1959. The 'Unsafe' in the name is a warning to users of this method that the underlying byte array is _not_ copied, and so could be susceptible to badly-behaving code manipulating the contents of the byte array after the `ResponseBytes` is handed to the calling code. If only the trusted SDK code has access to the original byte array before `ResponseBytes` is handed over to the caller, and once the `ResponseBytes` instance is handed over to the caller, the SDK code has no further use for the original byte array, then it is safe to use `ResponseBytes.fromByteArrayUnsafe()` in the trusted SDK code, and return the resulting `ResponseBytes` to the user, saving a double-allocation of memory, and the CPU time for the copying of bytes. See also: * aws/aws-sdk-java-v2#1959 * aws/aws-sdk-java-v2#1977
rtyley
added a commit
to rtyley/aws-sdk-async-response-bytes
that referenced
this pull request
Sep 2, 2023
Once the `ByteArrayAsyncResponseTransformer` has gathered all the response bytes, we still need to wrap those bytes and the response object in a `ResponseBytes` instance - but if we use `ResponseBytes.fromByteArray()`, a whole new byte array will be allocated, which is bad for two reasons: * While copying, the JVM heap must briefly hold both the old & new byte arrays - roughly speaking, doubling the memory requirements. * Copying the bytes from one array to another takes a little bit of CPU time (obviously this varies: `System.arraycopy()` for 40MB of bytes takes ~2ms on my M1 machine). A faster, more memory efficient alternative to `ResponseBytes.fromByteArray()` is `ResponseBytes.fromByteArrayUnsafe()`, added to the AWS SDK in August 2020 with aws/aws-sdk-java-v2#1977 in response to aws/aws-sdk-java-v2#1959. The 'Unsafe' in the name is a warning to users of this method that the underlying byte array is _not_ copied, and so could be susceptible to badly-behaving code manipulating the contents of the byte array after the `ResponseBytes` is handed to the calling code. If only the trusted SDK code has access to the original byte array before `ResponseBytes` is handed over to the caller, and once the `ResponseBytes` instance is handed over to the caller, the SDK code has no further use for the original byte array, then it is safe to use `ResponseBytes.fromByteArrayUnsafe()` in the trusted SDK code, and return the resulting `ResponseBytes` to the user, saving a double-allocation of memory, and the CPU time for the copying of bytes. See also: * aws/aws-sdk-java-v2#1959 * aws/aws-sdk-java-v2#1977
rtyley
added a commit
to rtyley/aws-sdk-async-response-bytes
that referenced
this pull request
Sep 2, 2023
Once the `ByteArrayAsyncResponseTransformer` has gathered all the response bytes, we still need to wrap those bytes and the response object in a `ResponseBytes` instance - but if we use `ResponseBytes.fromByteArray()`, a whole new byte array will be allocated, which is bad for two reasons: * While copying, the JVM heap must briefly hold both the old & new byte arrays - roughly speaking, doubling the memory requirements. * Copying the bytes from one array to another takes a little bit of CPU time (obviously this varies: `System.arraycopy()` for 40MB of bytes takes ~2ms on my M1 machine). A faster, more memory efficient alternative to `ResponseBytes.fromByteArray()` is `ResponseBytes.fromByteArrayUnsafe()`, added to the AWS SDK in August 2020 with aws/aws-sdk-java-v2#1977 in response to aws/aws-sdk-java-v2#1959. The 'Unsafe' in the name is a warning to users of this method that the underlying byte array is _not_ copied, and so could be susceptible to badly-behaving code manipulating the contents of the byte array after the `ResponseBytes` is handed to the calling code. If only the trusted SDK code has access to the original byte array before `ResponseBytes` is handed over to the caller, and once the `ResponseBytes` instance is handed over to the caller, the SDK code has no further use for the original byte array, then it is safe to use `ResponseBytes.fromByteArrayUnsafe()` in the trusted SDK code, and return the resulting `ResponseBytes` to the user, saving a double-allocation of memory, and the CPU time for the copying of bytes. See also: * aws/aws-sdk-java-v2#1959 * aws/aws-sdk-java-v2#1977
This was referenced Sep 2, 2023
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.
Reduced the number of payload data copies on some code paths.
Fixes #1959.