Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RetainableByteBuffer as mutable #11801

Merged
merged 92 commits into from
Jun 24, 2024
Merged

Conversation

gregw
Copy link
Contributor

@gregw gregw commented May 16, 2024

Opening this PR against 12.1.x rather than 12.0.x, replacing #11598

I'm just going to summarize the objectives of this PR:

  • Homogenize the APIs used for buffer manipulation in utils, aggregators, accumulators and buffers. Currently we have several different naming conventions and semantics (e.g. is the buffer consumed or not).
  • Reduce the API impedance between key abstractions. Buffers from Content.Sources should be compatible with buffers from ByteBufferPools and both should be easily written to Content.Sinks
  • Separate the read-only APIs from read-write APIs. The API used should indicate if buffer mutation is permitted or not.
  • protect mutable APIs from being applied to retained buffers
  • Avoid or hide modal APIs. Abstract away from the BB fill/flush mode issues so that these are rarely a concern for most buffer manipulations.
  • Where possible, internal implementations should leave BBs in the appropriate mode to avoid excess flipping
  • Remove unnecessary copies and encourage retention where possible and desirable.
  • Create common mechanisms that could allow heuristics decisions regarding copy vs retain, so that common usage does not need to make a hard coded choice.
  • Compatible with current buffer and API usage. We want evolution not revolution.
  • Avoid the complaints about BufferUtil and flipToFill and flipToFlush

@gregw
Copy link
Contributor Author

gregw commented May 27, 2024

@lorban Can you quickly go through and resolve any questions that you think are well enough answered?

@lorban
Copy link
Contributor

lorban commented May 28, 2024

@gregw the only point of contention I see is the behavior of accumulator.add() w.r.t the Retainable contract. I don't mind making an exception to the rules if that's properly javadoc'ed, as you did.

But this caught me by surprise, and I assume it could again in the future, more so if we multiply the exceptions. So I think there should be some hint in the method's name that it's not playing by the rules to suggest the caller of that API to go read the javadoc.

How about renaming add() to addPreRetained() or something like that? And maybe put it in bold at the top of the javadoc that an exception to the Retainable contract is being made?

@gregw
Copy link
Contributor Author

gregw commented May 29, 2024

But this caught me by surprise, and I assume it could again in the future, more so if we multiply the exceptions. So I think there should be some hint in the method's name that it's not playing by the rules to suggest the caller of that API to go read the javadoc.

@lorban I too was caught by surprise that we already have some accumulators that have this semantic behind a method called append, so this is not new behaviour.

How about renaming add() to addPreRetained() or something like that? And maybe put it in bold at the top of the javadoc that an exception to the Retainable contract is being made?

I'm open to change the name, but I don't like addPreRetained, @sbordet has referred to it as offer so we could use that name?

# Conflicts:
#	jetty-core/jetty-http2/jetty-http2-common/src/main/java/org/eclipse/jetty/http2/HTTP2Session.java
#	jetty-core/jetty-io/src/main/java/org/eclipse/jetty/io/ChunkAccumulator.java
@gregw
Copy link
Contributor Author

gregw commented Jun 11, 2024

@sbordet @lorban please don't forget this. Let's keep reviewing it and discussing it.
Can you at least resolve any conversations that I have answered... or indicate that the answer is not sufficient and there is more work to do.

@gregw gregw requested a review from lorban June 11, 2024 01:56
@gregw
Copy link
Contributor Author

gregw commented Jun 19, 2024

@sbordet @lorban I intend to merge this PR to 12.1.x tomorrow, unless there are any objections.

…r.DynamicCapacity

Signed-off-by: Ludovic Orban <lorban@bitronix.be>
Copy link
Contributor

@lorban lorban left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are a few nits left (see my comments) and I took care of a few TODOs related to usages of the deprecated ByteBufferPool.Accumulator, otherwise this looks like a good step forward.

@@ -581,14 +581,19 @@ private Pool.Entry<RetainableByteBuffer> evict()
}
}

private static class Buffer extends AbstractRetainableByteBuffer
private static class PooledBuffer extends RetainableByteBuffer.Pooled
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Almost only ArrayByteBufferPool makes use of this class so it could be made private for that purpose.
The only other usage is DynamicCapacity.takeByteArray() which prevents getting the array if the buffer is pooled, but that check contrasts with getByteBuffer() which does no such check.

I don't like very much this class being exposed as part of the buffer API,

lorban added 3 commits June 20, 2024 16:17
…r.DynamicCapacity

Signed-off-by: Ludovic Orban <lorban@bitronix.be>
…r.DynamicCapacity

Signed-off-by: Ludovic Orban <lorban@bitronix.be>
…r.DynamicCapacity

Signed-off-by: Ludovic Orban <lorban@bitronix.be>
@lorban
Copy link
Contributor

lorban commented Jun 20, 2024

I also noticed that tests inheriting from org.eclipse.jetty.http3.tests.AbstractClientServerTest leak buffers both on the client and the server, but that also happens without these changes so I reverted my change that adds the leak tracker.

@gregw gregw requested a review from lorban June 21, 2024 00:43
@gregw
Copy link
Contributor Author

gregw commented Jun 24, 2024

@lorban I think this is good to merge and get some prime time usage!?!?! no? 12.1.x will not be final for a while, so there is still time to make changes

Copy link
Contributor

@lorban lorban left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree to get this merged into 12.1.x.

There still are things that need to be cleaned up, and others that may be done differently but this is going to the right direction, already improves the current state and already is a large and complex PR.

@gregw gregw merged commit 36538d6 into jetty-12.1.x Jun 24, 2024
10 checks passed
@gregw gregw deleted the fix/jetty-12.1/10541/chunkAsRBB branch June 24, 2024 22:12
@gregw
Copy link
Contributor Author

gregw commented Jun 25, 2024

@lorban I have merged. Can you open issues for the things you want us to investigate more

@lorban
Copy link
Contributor

lorban commented Jun 25, 2024

@gregw I've opened the 5 enhancements listed above. AFAICS, we can consider this RBB refactoring is done once those are tackled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: ✅ Done
Development

Successfully merging this pull request may close these issues.

3 participants