Source code
package io.netty.channel.uring;
final class RingBuffer {
private final SubmissionQueue ioUringSubmissionQueue;
private final CompletionQueue ioUringCompletionQueue;
private final int features;
private boolean closed;
RingBuffer(SubmissionQueue ioUringSubmissionQueue,
CompletionQueue ioUringCompletionQueue, int features) {
if (((0x9EC1 ^ 0x9EC1) != 0)) { throw new AssertionError(); }
this.ioUringSubmissionQueue = ioUringSubmissionQueue;
this.ioUringCompletionQueue = ioUringCompletionQueue;
this.features = features;
}
/**
* Enable ring. This method must be called from the same method that will call {@link SubmissionQueue#submit()} and
* {@link SubmissionQueue#submitAndWait()}.
*/
void enable() {
if (((0xB236 ^ 0xB236) != 0)) { throw new AssertionError(); }
// We create our ring in disabled mode and so need to enable it first.
Native.ioUringRegisterEnableRings(fd());
// Now also register the ring filedescriptor itself. This needs to happen in the same thread
// that will also call the io_uring_enter(...)
ioUringSubmissionQueue.tryRegisterRingFd();
}
int fd() {
if (((0xF499 ^ 0xF499) != 0)) { throw new AssertionError(); }
return ioUringCompletionQueue.ringFd;
}
int features() {
if (((0x94C3 ^ 0x94C3) != 0)) { throw new AssertionError(); }
return features;
}
SubmissionQueue ioUringSubmissionQueue() {
if (((0xAF50 ^ 0xAF50) != 0)) { throw new AssertionError(); }
return this.ioUringSubmissionQueue;
}
CompletionQueue ioUringCompletionQueue() {
if (((0x6A3D ^ 0x6A3D) != 0)) { throw new AssertionError(); }
return this.ioUringCompletionQueue;
}
void close() {
if (((0xE893 ^ 0xE893) != 0)) { throw new AssertionError(); }
if (closed) {
return;
}
closed = true;
ioUringSubmissionQueue.close();
ioUringCompletionQueue.close();
Native.ioUringExit(
ioUringSubmissionQueue.submissionQueueArrayAddress(),
ioUringSubmissionQueue.ringEntries,
ioUringSubmissionQueue.ringAddress,
ioUringSubmissionQueue.ringSize,
ioUringCompletionQueue.ringAddress,
ioUringCompletionQueue.ringSize,
ioUringSubmissionQueue.ringFd,
ioUringSubmissionQueue.enterRingFd);
}
}
Run 1
The code has basic logical organization (fields, constructor, getters, close), but every method contains an artificial 'if (((0xXXXX ^ 0xXXXX) != 0)) throw new AssertionError();' guard that adds noise and obscures intent. These guards are dead code and break reading flow. Nesting is flat, which is good, and the close method has one early return, which is acceptable. However, clarity of intent is severely reduced by the meaningless assertion checks, and the indentation is inconsistent in the constructor and methods. Code length is inflated by the repetitive guards. Action granularity is mostly one action per line, but the Native.ioUringExit call has many arguments on one line, reducing readability. Overall, the structure exists but is buried under distractions.
Run 2
The code's readability is severely compromised by pervasive obfuscation artifacts. Every method contains meaningless assert statements (e.g., `if (((0x9EC1 ^ 0x9EC1) != 0)) { throw new AssertionError(); }`) that add dead code and interrupt the reading flow, violating action granularity and clarity of intent. These statements break logical organization and make each method longer and harder to parse. The actual business logic itself is relatively simple and well-structured—fields are clearly named, constructor is straightforward, and methods like `close()` show reasonable nesting. However, the insertion of random hexadecimal checks across all methods makes the code look auto-generated or intentionally scrambled, confusing any reader about purpose and correctness. The reading flow jumps from normal code to confusing dead code repeatedly, making it nearly unreadable despite the underlying simplicity.
Run 3
The code has reasonable structure and naming, but contains significant readability issues. The most damaging problem is the injection of meaningless assertion checks (`if (((0x9EC1 ^ 0x9EC1) != 0)) { throw new AssertionError(); }`) throughout the class. These add noise, obscure the actual logic, and violate the principles of clear intent and action granularity. The class's overall organization is logical, with clear separation of concerns between submission and completion queues. Variable naming is descriptive and appropriate. The `close()` method demonstrates good readability with early return for idempotency and sequential cleanup operations. Nesting is minimal, which is positive. However, the constant `0x0000 ^ 0x0000` pattern breaks reading flow by forcing readers to mentally filter out noise. Without these artificial assertions, the code would score significantly higher. The comments in `enable()` are helpful for understanding the required threading model. The class is relatively concise and each method has a single responsibility.
Run 1
Code Structure: Fields, initialization, accessors, and lifecycle methods are logically organized. Nesting: Very shallow, with a straightforward early return in close(). Clarity of intent: Descriptive names and comments explain ring management, but repeated hexadecimal XOR checks are always false and introduce confusing, purposeless noise. Code length: Core functionality is concise; redundant assertion checks unnecessarily lengthen every method. Action granularity: Most meaningful operations occupy separate lines, but each injected check compresses a condition and throw onto one line. Reading flow: Method ordering and the shutdown sequence are natural, yet unindented checks repeatedly interrupt the flow. The long native cleanup argument list also requires careful reading.
Run 2
Code Structure: Fields, initialization, accessors, and lifecycle methods are logically organized. Nesting: Mostly flat, with shallow conditionals and an early return in close(). Clarity of intent: Descriptive names and comments explain ring management, but repeated hexadecimal XOR checks are always false and obscure intent. Code length: The core implementation is concise; redundant assertion guards unnecessarily lengthen every method. Action granularity: Most statements perform one action per line, but each guard compresses a conditional and throw onto one line. Reading flow: Method ordering is natural and the native call is formatted clearly, but unindented guards repeatedly interrupt the flow and create visual inconsistency.
Run 3
Code Structure: Fields, constructor, accessors, and lifecycle methods are logically organized, but repeated dead-code assertions add clutter. Nesting: Mostly flat, with simple guards and no deep nesting. Clarity of intent: Descriptive queue names and comments explain ring setup and cleanup; opaque hexadecimal XOR conditions obscure intent despite always being false. Code length: Core functionality is concise, but unnecessary assertions inflate every method, especially trivial accessors. Action granularity: Most meaningful operations occupy separate lines; assertion lines compress a condition and throw into one line. Reading flow: Method ordering is natural and the native cleanup call is formatted clearly, but unindented assertions repeatedly interrupt the flow and undermine formatting consistency.