Make the alarm callback path thread-safe, roll back failed registrations, and stop losing callLater failures

[lagergren]

Three defects on the native alarm/callback path, in three commits. They share a theme: a failure on the timer or startup path that is lost rather than reported.

1. The callback registry is not safe for the thread that reads it

ServiceContext's callback registry was a lazily created HashMap — and the shared Java timer thread reads and removes from it while service threads add to it. A resizing put racing a get can corrupt the table structurally: entries in the wrong bins, unrelated keys lost. The values converge, so this is not "duplicate work"; it is a silent wrong answer from a registry.

Worse, WeakCallback.extractCallback() threw from that timer thread when the context was gone or the id already removed. Since java.util.Timer catches nothing, that throw cancels the process-wide Timer outright (that hazard is the subject of the companion PR; this one removes the known thrower). Cancelled alarms also leaked their registry entries.

Now: an eager final ConcurrentHashMap (ensureCallbackMap() deleted, getCallbackMap() never returns null), extractCallback() returns null instead of throwing, a new discard(), and both timer templates tolerate a null callback on fire and discard the entry on cancel.

2. Registration is not rolled back when startup fails

xLocalClock, xNanosTimer and xRTServer registered a container keep-alive before the operation that could fail. A failed timer schedule or a failed server bind therefore left the container pinned alive forever — it never goes idle, so it never terminates.

Adds rollbackBind/closeServerQuietly, guards registerKeepAlive against double-registration across a stop/start cycle, and plugs a leak where invokeSchedule registered a WeakCallback before addAlarm could throw.

3. callLater's completion handler silences failures it cannot classify

Both ServiceContext.callLater overloads carried:

future.whenComplete((r, x) -> {
    if (x != null) {
        callUnhandledExceptionHandler(((WrapperException) x).getExceptionHandle());
    }
});

((WrapperException) x) is a blind cast, and CompletableFuture swallows anything thrown inside whenComplete. So a wrong cast produces no visible ClassCastException — it produces the absence of the unhandled-exception handler ever running. The original failure is gone.

Stated honestly: this is latent, not currently firing. I traced it rather than assuming. whenComplete is attached to the root future (postRequest returns a plain new CompletableFuture(), not a dependent stage), so no CompletionException wrapping occurs; and both internal completion sites pass hException.getException(), whose declared type is WrapperException. On today's in-tree paths the cast never fires.

It is reachable through the published API, though: callLater returns its future to the caller, and future.cancel(true) completes it with CancellationException. No current caller does that — but it is a public method returning a public future, and the failure mode is total silence.

Fixed by routing both overloads through one reporter built on the runtime's own Utils.translate (already used for exactly this job in xFuture's completion callbacks): unwrap CompletionException/ExecutionException, map WrapperException as before, and render anything else visibly instead of dropping it — with the reporter itself wrapped so it can never throw back into the stage that would swallow it.

Why this one is worth more than a tidy-up

This is the sharpest available argument for typing a failure channel rather than casting it. A blind cast normally announces itself. Here the code being type-punned is the error-handling path, and the swallowing happens in a completion stage — so a wrong guess does not defer a failure to run time, it converts a reported failure into a lost one. That is strictly worse than an ordinary bad cast, and it is invisible by construction.

Tests

All behavioural. No source-text assertions — an earlier draft of this branch used them and they were removed, because they pin the shape of one particular fix rather than the behaviour, and would not have caught the original defects.

NativeCallbackRegistrationTest boots a real NativeContainer, builds a real ServiceContext and native entry Frame, and drives the real runtime classes. Five tests, all red on master. Highlights:

• registryToleratesConcurrentServiceAndTimerThreadAccess — 50,000 concurrent lookups. 12 failures / 12 runs on master, 0 / 12 after. This one is a genuine race: 12/12 on this machine is not a promise it fails everywhere.
• failedNanosTimerScheduleIsReportedAndUnwound — expected: <-3> but was: <-1>; master returned R_NEXT after a failed schedule, handing natural code an alarm that can never fire.
• extractingAMissingCallbackReturnsNullInsteadOfThrowing — catches the raw IllegalStateException that kills the shared Timer.

HttpServerBindRollbackTest binds real sockets on port 0 (ephemeral, both HTTP and HTTPS), starts both servers, then induces failure at the post-registration point and asserts on Container.isIdle() — the property the leak actually breaks. 10/10 red, 0/10 after.

CallLaterFailureReportingTest — two tests, one of which passes on master by design: it is the regression guard proving the ordinary WrapperException path is untouched, and it is also what empirically confirms the trace above. The failing one shows system-err: '' — the discarded failure leaves no trace at all.

:javatools:test 348 → 356, identical 40 pre-existing skips. xdk:installDist run as its own invocation; all results read from the JUnit XML.

Relationship to the other clock PR

Independent in both directions; either can land first. They conflict textually in xLocalClock.java and xNanosTimer.java, so whichever goes second wants a rebase. This PR removes the throwers we know about; the companion says the timer thread must survive one we do not.