Commit Graph

60 Commits

Author SHA1 Message Date
Chris Vest
917bfb24f7 Address the remaining PR comments from the prototype. 2020-11-17 15:26:57 +01:00
Chris Vest
3598c575d8 BBuf indexes are ints, not longs.
Motivation:
 We don't intend on support buffers bigger than 2 GiB, which is the max IO transfer size
 on Linux.

Modification:
 Change buffer read/write indexes to be ints, and add checks to allocators.

Result:
 BBuf is now int-sized and indexed.
2020-11-17 15:26:57 +01:00
Chris Vest
b5abfdd1f8 Address PR comments
Motivation:
 Clean up code to fix PR comments.

Modification:
 Rename a method and add javadocs.

Result:
 Code is cleaner and mode documented.
2020-11-17 15:26:57 +01:00
Chris Vest
8b0ea44f02 Add support for closing BBuf/MemorySegment via Cleaner
Motivation:
 Keeping track of refcounts is hard for client code.
 It is much easier to rely on the GC for cleanup.
Modification:
 Add a new pool, native allocator implementation, that uses the Cleaner API to prevent leaks.
 Native memory accounting, which is not built into the JDK for MemorySegments, has also been added to the allocators so the Cleaner based implementation can be tested.
Result:
 We have a leak resistant allocator for BBuf.
2020-11-17 15:26:57 +01:00
Chris Vest
c63403199e Fix compilation on updated JDK 16-ea
Motivation: The MemoryAccess API now takes MemorySegment instead of MemoryAddress.
Modification: Remove the MemoryAddress field and use MemorySegment everywhere.
Result: The code now compiles again.
2020-11-17 15:26:57 +01:00
Chris Vest
479abae9cd Access benchmark for BBuf
Motivation:
We want to be able to compare the performance of the existing ByteBuf implementation, and the new MemorySegment based BBuf.

Modification:
Copy the existing access benchmark for ByteBuf, and modify the copy to use the new BBuf instead.

Result:
We are able to get our first benchmark runs with BBuf.
The cost of accessing memory in BBuf is roughly twice that of the comparable ByteBuf implementations.
I think we'll need to improve this if we want BBuf to be a viable path forward.
2020-11-17 15:26:57 +01:00
Chris Vest
ddde3a42d9 Rename ...b2.ByteBuf -> ...b2.BBuf
Motivation:
Make it easier to use the existing ByteBuf and the new BBuf in the same source files.
To help transitioning between, and comparing, the two APIs.

Modification:
The new ...b2.ByteBuf class has been renamed to BBuf to avoid clashing with the existing ByteBuf name.

Result:
It's easier to make use of both classes in the same source files, since both can be imported independently.
2020-11-17 15:26:57 +01:00
Chris Vest
57af0f0e26 First spike prototype of a ByteBuf implementation based on MemorySegment
Motivation:
Future versions of Java will introduce a new API for working with off-heap and on-heap memory alike.
This API _could_ potentially relieve us of many of our use cases for Unsafe.
We wish to explore how suitable these APIs are for this task.

Modification:
Add an entirely separate version of the Netty ByteBuf API, implemented in terms of MemorySegment.
No existing code is changed at this time.
The current prototype is only to prove the concept, and does not aim to be a full replacement.

Result:
We are able to build a fairly nice API, but with caveats.
Restrictions in the current (JDK 16 EA) MemorySegment API, around how ownership is transferred between threads, means we are currently still relying on Unsafe.
While our use of Unsafe could be reduced, it can not be eliminated in our ByteBuf API, because we are relying on it to work around the current ownership restrictions.
I believe it is _possible_ to create a safe ownership transfer API at the JDK level, so hopefully this restriction can be lifted in the future.
2020-11-17 15:26:57 +01:00
Chris Vest
535184b7e7 Pom updates 2020-11-17 15:26:57 +01:00
Chris Vest
9f48b3c492 Prepare incubator repo for new buffer API 2020-11-17 14:56:28 +01:00