Add PooledSlicedByteBuf and PooledDuplicatedByteBuf #3788
Closed
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
|
@trustin @Scottmitch please review |
| writerIndex(length); | ||
| maxCapacity(length); | ||
| setIndex(0, length); | ||
| markReaderIndex(); |
There was a problem hiding this comment.
Should we wait for #3789 and update this to discardMarks?
There was a problem hiding this comment.
Yes :)
Am 15.05.2015 um 19:51 schrieb Scott Mitchell notifications@github.com:
In buffer/src/main/java/io/netty/buffer/SlicedByteBuf.java:
@@ -53,8 +61,10 @@ public SlicedByteBuf(ByteBuf buffer, int index, int length) {
adjustment = index;
}this.length = length;
writerIndex(length);maxCapacity(length);setIndex(0, length);markReaderIndex();—
Reply to this email directly or view it on GitHub.
Motivation: At the moment when calling slice(...) or duplicate(...) on a Pooled*ByteBuf a new SlicedByteBuf or DuplicatedByteBuf. This can create a lot of GC. Modifications: Add PooledSlicedByteBuf and PooledDuplicatedByteBuf which will be used when a PooledByteBuf is used. Result: Less GC.
|
LGTM |
|
@normanmaurer - good work! Can the branch be deleted? |
|
@Scottmitch done |
|
This change will be reverted. See #4138 |
Scottmitch
added a commit
to Scottmitch/netty
that referenced
this pull request
Aug 26, 2015
Motivation: Currently the "derived" buffer will only ever be recycled if the release call is made on the "derived" object, and the "wrapped" buffer ends up being "fully released" (aka refcount goes to 0). From my experience this is not the common use case and thus the "derived" buffers will not be recycled. Modifications: - revert netty#3788 Result: Less complexity, and less code to create new objects in majority of cases.
Scottmitch
added a commit
that referenced
this pull request
Aug 26, 2015
Motivation: Currently the "derived" buffer will only ever be recycled if the release call is made on the "derived" object, and the "wrapped" buffer ends up being "fully released" (aka refcount goes to 0). From my experience this is not the common use case and thus the "derived" buffers will not be recycled. Modifications: - revert #3788 Result: Less complexity, and less code to create new objects in majority of cases.
Scottmitch
added a commit
that referenced
this pull request
Aug 26, 2015
Motivation: Currently the "derived" buffer will only ever be recycled if the release call is made on the "derived" object, and the "wrapped" buffer ends up being "fully released" (aka refcount goes to 0). From my experience this is not the common use case and thus the "derived" buffers will not be recycled. Modifications: - revert #3788 Result: Less complexity, and less code to create new objects in majority of cases.
Scottmitch
added a commit
that referenced
this pull request
Aug 26, 2015
Motivation: Currently the "derived" buffer will only ever be recycled if the release call is made on the "derived" object, and the "wrapped" buffer ends up being "fully released" (aka refcount goes to 0). From my experience this is not the common use case and thus the "derived" buffers will not be recycled. Modifications: - revert #3788 Result: Less complexity, and less code to create new objects in majority of cases.
Scottmitch
added a commit
to Scottmitch/netty
that referenced
this pull request
Aug 26, 2015
Motivation: As part of the revert process in netty#4138 some index and mark updates were lost. Modifications: - Restore the index / mark updates made in netty#3788 Result: Slice and Duplicate buffers index / marks are correctly initialized.
pulllock
pushed a commit
to pulllock/netty
that referenced
this pull request
Oct 19, 2023
Motivation: Currently the "derived" buffer will only ever be recycled if the release call is made on the "derived" object, and the "wrapped" buffer ends up being "fully released" (aka refcount goes to 0). From my experience this is not the common use case and thus the "derived" buffers will not be recycled. Modifications: - revert netty#3788 Result: Less complexity, and less code to create new objects in majority of cases.
pulllock
pushed a commit
to pulllock/netty
that referenced
this pull request
Oct 19, 2023
Motivation: As part of the revert process in netty#4138 some index and mark updates were lost. Modifications: - Restore the index / mark updates made in netty#3788 Result: Slice and Duplicate buffers index / marks are correctly initialized.
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.
Motivation:
At the moment when calling slice(...) or duplicate(...) on a Pooled*ByteBuf a new SlicedByteBuf or DuplicatedByteBuf. This can create a lot of GC.
Modifications:
Add PooledSlicedByteBuf and PooledDuplicatedByteBuf which will be used when a PooledByteBuf is used.
Result:
Less GC.