a3f6ae6be8
When send() a confined buffer, we had to first turn it into a shard buffer, so that it could be claimed by an arbitrary recipient thread. As we've learned, however, closing shared segments is expensive. We can speed up the send() call by simply leaving the segment shared. This weakens the confinement of the received segment, though. Currently no tests fails on that, but in the future we should re-implement confinement checking inside the Buf implementations themselves any, because pooled buffers also violate the confinement restriction, and we have a guiding principle that all buffers, regardless of implementation, should always behave the same. The results of this change can be observed in the MemorySegmentClosedByCleanerBenchmark, with the heavy workload. Explicitly closed segments now run the workload twice as fast, and the cleaner based closing is now 3 times faster. Before: Benchmark (workload) Mode Cnt Score Error Units MemorySegmentClosedByCleanerBenchmark.cleanerClose heavy avgt 150 42,221 ± 0,943 us/op MemorySegmentClosedByCleanerBenchmark.explicitClose heavy avgt 150 65,215 ± 0,761 us/op After: Benchmark (workload) Mode Cnt Score Error Units MemorySegmentClosedByCleanerBenchmark.cleanerClose heavy avgt 150 13,871 ± 0,544 us/op MemorySegmentClosedByCleanerBenchmark.explicitClose heavy avgt 150 37,516 ± 0,426 us/op
Netty Incubator Buffer API
This repository is incubating a new buffer API proposed for Netty 5.
Building and Testing
Short version: just run make.
The project currently relies on snapshot versions of the Panama Foreign fork of OpenJDK.
This allows us to test out the must recent version of the jdk.incubator.foreign APIs, but also make building and local development more involved.
To simplify things, we have a Docker based build, controlled via a Makefile with the following commands:
image– build the docker image. This includes building a snapshot of OpenJDK, and download all relevant Maven dependencies.test– run all tests in a docker container. This impliesimage. The container is automatically deleted afterwards.dbg– drop into a shell in the build container, without running the build itself. The debugging container is not deleted afterwards.clean– remote the debugging container created bydbg.build– build binaries and run all tests in a container, and copy thetargetdirectory out of the container afterwards. This is the default build target.