4a409d2458
Motivation: Pooled buffers are a very important use case, and they change the cost dynamics around shared memory segments, so it's worth looking into in detail. Modification: Add another explicit close of pooled direct buffers to MemorySegmentClosedByCleanerBenchmark Result: Explicitly closing of pooled buffers is even out-performing cleaner close on the "heavy" workload, so this is currently the fastest way to run that workload: Benchmark (workload) Mode Cnt Score Error Units MemorySegmentClosedByCleanerBenchmark.cleanerClose heavy avgt 150 14,194 ± 0,558 us/op MemorySegmentClosedByCleanerBenchmark.explicitClose heavy avgt 150 40,496 ± 0,414 us/op MemorySegmentClosedByCleanerBenchmark.explicitPooledClose heavy avgt 150 12,723 ± 0,134 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.