Commit Graph

940 Commits

Author SHA1 Message Date
root
01b7e18632 [maven-release-plugin] prepare for next development iteration 2020-10-13 06:29:26 +00:00
root
d4a0050ef3 [maven-release-plugin] prepare release netty-4.1.53.Final 2020-10-13 06:29:02 +00:00
Matthew Kavanagh
d3a41b8b9a
Avoid integer overflow in ByteBuf.ensureWritable (#10648)
Motivation:

- To make ensureWritable throw IOOBE when maxCapacity is exceeded, even if
the requested new capacity would overflow Integer.MAX_VALUE

Modification:

- AbstractByteBuf.ensureWritable0 is modified to detect when
targetCapacity has wrapped around
- Test added for correct behaviour in AbstractByteBufTest

Result:

- Calls to ensureWritable will always throw IOOBE when maxCapacity is
exceeded (and bounds checking is enabled)
2020-10-12 09:23:32 +02:00
Francesco Nigro
162e59848a
Improve predictability of writeUtf8/writeAscii performance (#10368)
Motivation:

writeUtf8 can suffer from inlining issues and/or megamorphic call-sites on the hot path due to ByteBuf hierarchy

Modifications:

Duplicate and specialize the code paths to reduce the need of polymorphic calls

Result:

Performance are more stable in user code
2020-09-09 16:10:26 +02:00
root
957ef746d8 [maven-release-plugin] prepare for next development iteration 2020-09-08 05:26:25 +00:00
root
ada9c38c0a [maven-release-plugin] prepare release netty-4.1.52.Final 2020-09-08 05:26:05 +00:00
Graham Edgecombe
a99a8f2a1f
Fix ByteBufUtil.getBytes() incorrectly sharing the array in some cases (#10529)
Motivation:

If ByteBufUtil.getBytes() is called with copy=false, it does not
correctly check that the underlying array can be shared in some cases.

In particular:

* It does not check that the arrayOffset() is zero. This causes it to
  incorrectly return the underlying array if the other conditions are
  met. The returned array will be longer than requested, with additional
  unwanted bytes at its start.

* It assumes that the capacity() of the ByteBuf is equal to the backing
  array length. This is not true for some types of ByteBuf, such as
  PooledHeapByteBuf. This causes it to incorrectly return the underlying
  array if the other conditions are met. The returned array will be
  longer than requested, with additional unwanted bytes at its end.

Modifications:

This commit fixes the two bugs by:

* Checking that the arrayOffset() is zero before returning the
  underlying array.

* Comparing the requested length to the underlying array's length,
  rather than the ByteBuf's capacity, before returning the underlying
  array.

This commit also adds a series of test cases for ByteBufUtil.getBytes().

Result:

ByteBufUtil.getBytes() now correctly checks whether the underlying array
can be shared or not.

The test cases will ensure the bug is not reintroduced in the future.
2020-09-04 13:15:35 +02:00
Nick Hill
b908c82b7b
Lazily construct contained DataOutputStream in ByteBufOutputStream (#10507)
Motivation

This is used solely for the DataOutput#writeUTF8() method, which may
often not be used.

Modifications

Lazily construct the contained DataOutputStream in ByteBufOutputStream.

Result

Saves an allocation in some common cases
2020-08-28 09:22:58 +02:00
Nick Hill
8e8f01e01d
Use ByteBuf#isAccessible() in more places (#10506)
Motivation

ByteBuf has an isAccessible method which was introduced as part of ref
counting optimizations but there are some places still doing
accessibility checks by accessing the volatile refCnt() directly.

Modifications

- Have PooledNonRetained(Duplicate|Sliced)ByteBuf#isAccessible() use
their refcount delegate's isAccessible() method
- Add static isAccessible(buf) and ensureAccessible(buf) methods to
ByteBufUtil
(since ByteBuf#isAccessible() is package-private)
- Adjust DefaultByteBufHolder and similar classes to use these methods
rather than access refCnt() directly

Result

- More efficient accessibility checks in more places
2020-08-28 09:18:13 +02:00
Norman Maurer
4e86f768b9
Reduce the scope of synchronized block in PoolArena (#10410)
Motivation:

We shouldn't call incSmallAllocation() in a synchronized block as its backed by a concurrent datastructure

Modifications:

Move call of incSmallAllocation() out of synchronized block

Result:

Minimize scope of synchronized block
2020-07-16 19:40:40 +02:00
Ruwei
7caced28c6
Review PooledByteBufAllocator in respect of jemalloc 4.x changes and update allocate algorithm.(#10267)
Motivation:

For size from 512 bytes to chunkSize, we use a buddy algorithm. The
drawback is that it has a large internal fragmentation.

Modifications:

1. add SizeClassesMetric and SizeClasses
2. remove tiny size, now we have small, normal and huge size
3. rewrite the structure of PoolChunk
4. rewrite pooled allocate algorithm in PoolChunk
5. when allocate subpage, using lowest common multiple of pageSize and
   elemSize instead of pageSize.
   6. add more tests in PooledByteBufAllocatorTest and PoolArenaTest

Result:
Reduce internal fragmentation and closes #3910
2020-07-15 21:33:27 +02:00
root
bfbeb2dec6 [maven-release-plugin] prepare for next development iteration 2020-07-09 12:27:06 +00:00
root
646934ef0a [maven-release-plugin] prepare release netty-4.1.51.Final 2020-07-09 12:26:30 +00:00
Norman Maurer
6e0d22335d
Include more details if we throw an IllegalArgumentException because of overflow (#10330)
Motivation:

We should include as much details as possible when throwing an IllegalArgumentException because of overflow in CompositeByteBuf

Modifications:

Add more details and factor out check into a static method to share code

Result:

Make it more clear why an operations failed
2020-06-02 10:07:50 +02:00
root
caf51b7284 [maven-release-plugin] prepare for next development iteration 2020-05-13 06:00:23 +00:00
root
8c5b72aaf0 [maven-release-plugin] prepare release netty-4.1.50.Final 2020-05-13 05:59:55 +00:00
Nick Hill
c3db0391af
Correctly handle WrappedCompositeByteBufs in addFlattenedComponents() (#10247)
Motivation

An NPE was reported in #10245, caused by a regression introduced in
#8939. This in particular affects ByteToMessageDecoders that use the
COMPOSITE_CUMULATOR.

Modification

- Unwrap WrappedCompositeByteBufs passed to
CompositeByteBuf#addFlattenedComponents(...) method before accessing
internal components field
- Extend unit test to cover this case and ensure more of the
CompositeByteBuf tests are also run on the wrapped variant

Results

Fixes #10245
2020-05-05 13:56:40 +02:00
Norman Maurer
5a08dc0d9a
Add fastpath implementation for Unpooled.copiedBuffer(CharSequence, Charset) when UTF-8 or US-ASCII is used (#10206)
Motivation:

We can make use of our optimized implementations for UTF-8 and US-ASCII if the user request a copy of a sequence for these charsets

Modifications:

- Add fastpath implementation
- Add unit tests

Result:

Fixes https://github.com/netty/netty/issues/10205
2020-04-23 17:47:16 +02:00
root
9c5008b109 [maven-release-plugin] prepare for next development iteration 2020-04-22 09:57:54 +00:00
root
d0ec961cce [maven-release-plugin] prepare release netty-4.1.49.Final 2020-04-22 09:57:26 +00:00
Norman Maurer
232c669fa4
Guard against overflow when calling CompositeByteBuf.addComponent(...) (#10197)
Motivation:

We need to ensure we not overflow when adding buffers to a CompositeByteBuf

Modifications:

- Correctly validate overflow before adding to the internal storage
- Add testcase

Result:

Fixes https://github.com/netty/netty/issues/10194
2020-04-21 12:04:25 +02:00
Linas Medžiūnas
fb5e2cd3aa
Efficient BytBuf search algorithms (#9914) (#9955)
Motivation:

We have found out that ByteBufUtil.indexOf can be inefficient for substring search on
ByteBuf, both in terms of algorithm complexity (worst case O(needle.readableBytes *
haystack.readableBytes)), and in constant factor (esp. on Composite buffers).
With implementation of more performant search algorithms we have seen improvements on
the order of magnitude.

Modifications:

This change introduces three search algorithms:
1. Knuth Morris Pratt - classical textbook algorithm, a good default choice.
2. Bit mask based algorithm - stable performance on any input, but limited to maximum
search substring (the needle) length of 64 bytes.
3. Aho–Corasick - worse performance and higher memory consumption than [1] and [2], but
it supports multiple substring (the needles) search simultaneously, by inspecting every
byte of the haystack only once.

Each algorithm processes every byte of underlying buffer only once, they are implemented
as ByteProcessor.

Result:

Efficient search algorithms with linear time complexity available in Netty (I will share
benchmark results in a comment on a PR).
2020-04-15 10:21:24 +02:00
时无两丶
ff6d2e4949
Remove duplicate code in PoolArena. (#10174)
Motivation:

Remove duplicate code in PoolArena.

Modification:

Replace duplicate code with `tinyIdx` and `smallIdx`.

Result:

Clean code.
2020-04-15 09:29:23 +02:00
Dmitry Konstantinov
05b7af7ae4
Propagate ref to pool thread cache down in the allocation stack to avoid extra thread local lookup (#10166)
Motivation:
PoolChunk requires a link to a PoolThreadCache to init ByteBuf. Currently the link is retrieved from a thread local: arena.parent.threadCache().
It has some performance cost. At the beginning of the allocation call the PoolThreadCache is already retrieved from the thread local. The reference can be propagated through the calls and used.

Modifications:
Replace second lookup of PoolThreadCache during ByteBuf init by propagation of a reference to PoolThreadCache down in the allocation stack explicitly

Result:
Improve performance of ByteBuf allocation
--Before--
Benchmark                                            (size)  (tokens)  (useThreadCache)  Mode  Cnt    Score   Error  Units
SimpleByteBufPooledAllocatorBenchmark.getAndRelease     123         0              true  avgt   20   57.112 ± 1.004  ns/op
SimpleByteBufPooledAllocatorBenchmark.getAndRelease     123       100              true  avgt   20  222.827 ± 1.307  ns/op

--After--
Benchmark                                            (size)  (tokens)  (useThreadCache)  Mode  Cnt    Score   Error  Units
SimpleByteBufPooledAllocatorBenchmark.getAndRelease     123         0              true  avgt   20   50.732 ± 1.321  ns/op
SimpleByteBufPooledAllocatorBenchmark.getAndRelease     123       100              true  avgt   20  216.892 ± 3.806  ns/op
2020-04-06 08:01:01 +02:00
Dmitry Konstantinov
ea31b59037
Replace usage() with freeBytes() in thresholds within hot paths of PoolChunkList (#10141)
Motivation:
PoolChunk.usage() method has non-trivial computations. It is used currently in hot path methods invoked when an allocation and de-allocation are happened.
The idea is to replace usage() output comparison against percent thresholds by Chunk.freeBytes plain comparison against absolute thresholds. In such way the majority of computations from the threshold conditions are moved to init logic.

Modifications:
Replace PoolChunk.usage() conditions in PoolChunkList with equivalent conditions for PoolChunk.freeBytes()

Result:
Improve performance of allocation and de-allocation of ByteBuf from normal size cache pool
2020-03-31 22:11:16 +02:00
Dmitry Konstantinov
913cae6fef
Optimize log2 in PoolThreadCache (#10128)
Motivation:
The current implementation of log2 in PoolThreadCache uses a loop and less efficient than an version based on Integer.numberOfLeadingZeros (intrinsic).

Modifications:
Replace the current log2 implementation in PoolThreadCache with a version based on Integer.numberOfLeadingZeros

Result:
It can improve performance slightly during allocation and de-allocation of ByteBuf using pooled allocator.
2020-03-24 11:13:52 +01:00
root
14e4afeba2 [maven-release-plugin] prepare for next development iteration 2020-03-17 09:20:54 +00:00
root
c10c697e5b [maven-release-plugin] prepare release netty-4.1.48.Final 2020-03-17 09:18:28 +00:00
root
c623a50d19 [maven-release-plugin] prepare for next development iteration 2020-03-09 12:13:56 +00:00
root
a401b2ac92 [maven-release-plugin] prepare release netty-4.1.47.Final 2020-03-09 12:13:26 +00:00
root
e0d73bca4d [maven-release-plugin] prepare for next development iteration 2020-02-28 06:37:33 +00:00
root
ebe7af5102 [maven-release-plugin] prepare release netty-4.1.46.Final 2020-02-28 06:36:45 +00:00
Norman Maurer
a3e5e4876c
FixedCompositeByteBuf.isDirect() may return wrong value when constructed with empty array (#10005)
Motivation:

FixedCompositeByteBuf.isDirect() should return the same value as EMPTY_BUFFER.isDirect() when constructed via an empty array

Modifications:

- Return correct value when constructed via empty array.
- Add unit test

Result:

FixedCompositeByteBuf.isDirect() returns correct value
2020-02-08 17:05:26 +01:00
Norman Maurer
07149729cc
Use correct system property name in PooledByteBufAllocator (io.netty.allocator.cacheTrimIntervalMillis) (#9994)
Motivation:

We had a typo in the system property name that was used to lookup the cache trime interval. We should ensure we use the correct naming when lookup the property

Modifications:

- Support the old and the new (correct) naming of the property when configure the cache trim interval.
- Log something if someone uses the old (deprecated) name

Result:

Fixes https://github.com/netty/netty/issues/9981
2020-02-05 14:39:23 +01:00
root
9b1ea10a12 [maven-release-plugin] prepare for next development iteration 2020-01-13 09:13:53 +00:00
root
136db8680a [maven-release-plugin] prepare release netty-4.1.45.Final 2020-01-13 09:13:30 +00:00
Nick Hill
607bc05a2c Fix BufferOverflowException during non-Unsafe PooledDirectByteBuf resize (#9912)
Motivation

Recent optimization #9765 introduced a bug where the native indices of
the internal reused duplicate nio buffer are not properly reset prior to
using it to copy data during a reallocation operation. This can result
in BufferOverflowExceptions thrown during ByteBuf capacity changes.

The code path in question applies only to pooled direct buffers when
Unsafe is disabled or not available.

Modification

Ensure ByteBuffer#clear() is always called on the reused internal nio
buffer prior to returning it from PooledByteBuf#internalNioBuffer()
(protected method); add unit test that exposes the bug.

Result

Fixes #9911
2020-01-11 06:04:32 +01:00
root
79d4e74019 [maven-release-plugin] prepare for next development iteration 2019-12-18 08:32:54 +00:00
root
5ddf45a2d5 [maven-release-plugin] prepare release netty-4.1.44.Final 2019-12-18 08:31:43 +00:00
Norman Maurer
9a0ccf24f3
Add unit test for leak aware CompositeByteBuf that proves that there is no NPE (#9875)
Motivation:

https://github.com/netty/netty/issues/9873 reported a NPE in previous version of netty. We should add a unit test to verify there is no more NPE

Modifications:

Add a unit test

Result:

Prove that https://github.com/netty/netty/issues/9873 is fixed
2019-12-12 16:18:27 +01:00
Sergey Skrobotov
84547029d9 Change DefaultByteBufHolder.equals() to treat instances of different classes as not equal (#9855)
# Motivation:
`DefaultByteBufHolder.equals()` considers another object equal if it's an instance of `ByteBufferHolder` and if the contents of two objects are equal. However, the behavior of `equals` method is not a part of the `ByteBufHolder` contract so `DefaultByteBufHolder`'s version may be causing violation of the symmetric property if other classes have different logic.
There are already a few classes that are affected by this: `DefaultHttp2GoAwayFrame`, `DefaultHttp2UnknownFrame`, and `SctpMessage` are all overriding `equals` method breaking the symmetric property.
Another effect of this behavior is that all instances with empty data are considered equal. That may not be desireable in the situations when instances are created for predefined constants, e.g. `FullBulkStringRedisMessage.NULL_INSTANCE` and `FullBulkStringRedisMessage.EMPTY_INSTANCE` in `codec-redis`. 

# Modification:
Make `DefaultByteBufHolder.equals()` implementation only work for the objects of the same class.

# Result:
- The symmetric property of the `equals` method is restored for the classes in question.
- Instances of different classes are not considered equal even if the content of the data they hold are the same.
2019-12-10 11:29:44 +01:00
时无两丶
0cde4d9cb4 Uniform null pointer check. (#9840)
Motivation:
Uniform null pointer check.

Modifications:

Use ObjectUtil.checkNonNull(...)

Result:
Less code, same result.
2019-12-09 09:47:35 +01:00
Nick Hill
63d33b390a Minor simplifications/optimizations to AbstractByteBuf methods (#9845)
Motivation

While working on other changes I noticed some opportunities to
streamline a few things in AbstractByteBuf.

Modifications

- Avoid duplicate ensureAccessible() checks in discard(Some)ReadBytes()
and ensureWritable0(int) methods
- Simplify ensureWritable0(int) logic
- Make some conditional checks more concise

Result

Cleaner, possibly faster code
2019-12-05 11:32:21 +01:00
Nick Hill
b0feb5a81f Reduce ByteBuffer duplication when resizing pooled direct ByteBufs (#9765)
Motivation:

Currently when use of Unsafe is disabled and an internal reallocation is
performed for a direct PooledByteBuf, a one-off temporary duplicate is
made of the source and destination backing nio buffers so that the
copy can be done in a threadsafe manner.

The need for this can be reduced by sharing the temporary duplicate
buffer that is already stored in the corresponding destination
PooledByteBuf instance.

Modifications:

Have PoolArena#memoryCopy(...) take the destination PooledByteBuf
instead of the underlying mem reference and offset, and use
internalNioBuffer() to obtain/initialize a reusable duplicate of the
backing nio buffer.

Result:

Fewer temporary allocations when resizing direct pooled ByteBufs in the
non-Unsafe case
2019-11-16 11:26:02 -08:00
Nick Hill
535d598492 Introduce ByteBuf#isContiguous() method (#9735)
Motivation

There's currently no way to determine whether an arbitrary ByteBuf
behaves internally like a "singluar" buffer or a composite one, and this
can be important to know when making decisions about how to manipulate
it in an efficient way.

An example of this is the ByteBuf#discardReadBytes() method which
increases the writable bytes for a contiguous buffer (by readerIndex)
but does not for a composite one.

Unfortunately !(buf instanceof CompositeByteBuf) is not reliable, since
for example this will be true in the case of a sliced CompositeByteBuf
or some third-party composite implementation.

isContiguous was chosen over isComposite since we want to assume "not
contiguous" in the unknown/default case - the doc will it clear that
false does not imply composite.

Modifications

- Add ByteBuf#isContiguous() which returns true by default
- Override the "concrete" ByteBuf impls to return true and ensure
wrapped/derived impls delegate it appropriately
- Include some basic unit tests

Result

Better assumptions/decisions possible when manipulating arbitrary
ByteBufs, for example when combining/cumulating them.
2019-11-06 12:06:25 +01:00
Norman Maurer
6c061abc49
Hide Recycler implemention to allow experimenting with different implementions of an Object pool (#9715)
Motivation:

At the moment we directly extend the Recycler base class in our code which makes it hard to experiment with different Object pool implementation. It would be nice to be able to switch from one to another by using a system property in the future. This would also allow to more easily test things like https://github.com/netty/netty/pull/8052.

Modifications:

- Introduce ObjectPool class with static method that we now use internally to obtain an ObjectPool implementation.
- Wrap the Recycler into an ObjectPool and return it for now

Result:

Preparation for different ObjectPool implementations
2019-10-26 00:34:30 -07:00
Nick Hill
f4b4a44c7c Change javadoc of ByteBuf#indexOf(...) to match its behaviour (#9679)
Motivation

Currently doc != code and so one needs to change. Though behaviour as
currently documented might be more intuitive, we don't want to break
anyone so will adjust the doc instead. See #9503 for discussion.

Modifications

Correct the javadoc of indexOf(...) method in ByteBuf abstract class.

Results

Correct javadoc
2019-10-24 23:42:30 -07:00
root
844b82b986 [maven-release-plugin] prepare for next development iteration 2019-10-24 12:57:00 +00:00
root
d066f163d7 [maven-release-plugin] prepare release netty-4.1.43.Final 2019-10-24 12:56:30 +00:00
root
92941cdcac [maven-release-plugin] prepare for next development iteration 2019-09-25 06:15:31 +00:00