GeezerVison

Description

ObjectTable (added in #2099) guarded its tables with java.util.concurrent.locks.StampedLock: write locks for mutations, optimistic reads elsewhere. On device, StampedLock runs interpreted. It lives in the boot classpath (core-oj) but outside the boot image, and an app's baseline profile can't compile boot-classpath methods. A profile of NativeScript core's apps/automated suite showed StampedLock.tryWriteLock/casState/writeLock/unlockWriteInternal running in the interpreter on the main thread.

This replaces it with synchronized (this). An uncontended monitor enter/exit is compiled into every caller. Reads now take the lock too, so the torn-read handling the optimistic path needed (findIdUnlocked, getUnlocked) is gone. A second commit makes the table concurrent on every API level. It was limited to API 24+ only because StampedLock needs it. On API 21–23, argument objects were resolved natively under the isolate lock and new ids took a separate path; now every level registers through findOrRegister. findIdOptimistic is merged into findId, and getOrCreateObjectId takes one lock instead of a lookup followed by a registration.

JNI microbenchmarks (debug.ns.jnibench, optimized release, SM-G780G; main and this branch interleaved, 2 passes × 3 runs; median ns):

The other rows are within ±2%. Even after the JIT has compiled it, StampedLock's write path was costly.

Known trade-off: when 2–4 Java threads call into JS at the same time, their object-id lookups used to be lock-free optimistic reads and now contend on the monitor: +3..+6% in those benchmarks. Apps run JS on one thread in the common case, where this is a clear win.

Real apps: no measurable difference on the template app's cold start (497/491 vs 503/494 ms) or on a 1000-tile flex-wrap mount. The phone was thermally throttling during that comparison, so those numbers only rule out a large effect.

Does your commit message include the wording below to reference a specific issue in this repo?

No issue.

Related Pull Requests

• perf: faster object lifecycle and JNI calls #2099 introduced ObjectTable.

Does your pull request have unit tests?

Yes. The ObjectTable JVM test for concurrent readers and a writer now requires every read of a stable entry to hit; it used to allow optimistic misses. The test for disabled optimistic reads is gone with the flag. JVM tests: 29/29.

Full device suite:

• API 36 emulator: 1551 specs, 0 failures.
• API 23 emulator (arm64): 1551 specs, 3 failures, the same 3 that main fails on that emulator:
  • a proxy test that matches ByteBuffer.toString()'s newer cap= format;
  • two HTTP module-import tests that time out.

On API 23 the harness also reports "App has crashed - ErrorReportActivity" for both main and this PR. run-as ... ls exits 0 there even when the file is missing, so the harness's checks misfire; the results were read from the XML directly.

Summary by CodeRabbit

• Bug Fixes
  • Improved the reliability of object lookups when multiple threads access the runtime, helping ensure stable objects return the correct identifiers.
  • Object registration, lookup, retrieval, and removal now use consistent synchronization, reducing the risk of inconsistent results during concurrent access.
  • Updated object argument handling to register objects without an existing identifier and correctly mark newly registered objects.