chore(ilp): review changes, reducing allocations#22
Merged
Merged
Conversation
SegmentManager's hot-spare provisioning previously allocated a fresh byte[] and a NATIVE_PATH-tagged native malloc on every rotation: StringSink.toString() produced a String, Files.openCleanRW(String) encoded it back into native memory via pathPtr(), and the same encoding repeated for any cleanup remove(). With small segments and high throughput the per-rotation churn becomes proportional to the rotation rate. Replace the StringSink with a reusable DirectUtf8Sink (pathScratch) that the worker thread writes directly. nextSparePath() builds the path bytes in place, captures the display String once for MmapSegment.path() and exception messages, then appends a NUL byte so the same buffer is a valid C string for the long-ptr Files overloads. Files / FilesFacade / DefaultFilesFacade gain three new overloads that accept a pre-encoded native pointer: openRW(long), openCleanRW(long, long), length(long). Each is a direct passthrough to the existing JNI native, no allocation. MmapSegment.create grows a parallel long-ptr factory: create(FilesFacade, long pathPtr, String displayPath, ...). The existing String-taking factories delegate through it via allocNativePath, preserving the public API while concentrating the open + allocate + mmap dance in one place. SegmentManager calls the new factory directly with pathScratch.ptr(). Per rotation the byte[] and the NATIVE_PATH malloc/free pair are gone. The one remaining String allocation (pathScratch.toString()) stays because MmapSegment.path() returns String for trim and log lines -- killing that would require a different segment-identity representation and is out of scope here. Test seam: FaultyFilesFacade in MmapSegmentTest mirrors the new long-ptr overloads (openCleanRW(long, long), openRW(long), length(long), remove(long) counter) so the create-time fault injection contracts still fire after the String factory routes internally through the pointer factory. Drive-by: replace frameCount++ in MmapSegment.tryAppend with an explicit volatile read + write to silence the "non-atomic increment of volatile" inspection. Semantics unchanged -- the field has a single writer by design (producer thread in tryAppend), so the read-modify-write race the inspection warns about cannot occur. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
bluestreak01
changed the title
Contributor
[PR Coverage check]😍 pass : 23 / 29 (79.31%) file detail
|
bluestreak01
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.