perf: faster object lifecycle and JNI calls - #2099

…e lock

com.tns.Runtime kept four maps per runtime (id -> object and object -> id,
each strong and weak), wrapped in synchronizedMap/ConcurrentHashMap when
multithreaded JS is enabled. Every JS wrapper creation, object return and
finalization paid for those locks, a second WeakReference per object, and
NativeScriptHashMap entry allocations.

They are replaced by one ObjectTable: open addressing over the object id and
over System.identityHashCode, no per-entry allocation, no locks. Its rule is
that only the thread holding the runtime's isolate lock touches it, so the
accesses that used to happen in Java before the lock now happen natively
after taking it: the receiver of a multithreaded Java -> JS call and every
object argument are resolved (and new objects registered) in
callJSMethodNative, and createJSInstance registers inside
createJSInstanceNative. With multithreaded JS off the receiver is still
resolved on the runtime's own thread, as before.

Object ids stay monotonic, so native caches keyed by them never see a reused
id. NativeScriptHashMap, NativeScriptWeakHashMap and NativeScriptAbstractMap
have no other users and are removed.

Resolving every object argument natively cost a JNI upcall per argument
inside the lock. ObjectTable gains an optimistic read (StampedLock,
API 24+) that any thread may make: writers, already serialized by the
isolate lock, bracket each mutation with the write stamp, and a reader that
overlaps one gets a miss instead of a torn result. Java passes the ids it
reads this way as hints for the receiver and object arguments; the native
side uses a hint only when it names a still-linked wrapper (ids are never
reused) and resolves exactly under the lock otherwise.

… each

A JS wrapper's finalizer called Java once per collected wrapper, on its first
collection to weaken the Java object and on later ones to ask whether it was
still alive. The finalizer now revives the wrapper and queues its id; one
processFinalizedBatch call weakens or checks the whole batch through two int
arrays and reports the dead ids, whose wrappers are then released. A batch is
flushed inside the finalizer once it reaches 1024 ids, so a long synchronous
JS loop holds at most that many Java objects strongly past their wrappers'
collection, and otherwise from the event loop (V8 runs the GC epilogue before
the finalizers).

Every native upcall into the object table now asserts, in debug builds, that
the calling thread holds the isolate lock.

Finalizers only queue ids now; the batch is flushed when JS next calls into
Java or Java next calls into JS, with the posted event-loop task as the
fallback for a thread that goes idle. JS cannot create or receive a Java
object without crossing, so Java objects kept strong for collected wrappers
cannot pile up during a long synchronous stretch, and nothing calls into
Java or frees other handles inside V8's finalizer pass.

A wrapper handed back to JS while its id is queued is skipped by the flush,
so its Java object is not weakened or released while JS holds it. A failed
flush (Java OOM) is retried after a pause instead of throwing out of a
finalizer or into an unrelated JS call. releaseNativeCounterpart is no
longer public, since it may only run under the isolate lock.

Java hands every class a dense index (once per class per process) and sends
it with each object: packed next to the id hint for Java->JS arguments, and
returned with the id by the single upcall native already makes for returns
and field reads. Native caches the class's JNI name and a global ref of the
object's own class by that index, so wrapping a new object no longer calls
Class.getName() and FindClass, and links the wrapper to the exact runtime
class even when another loader defines the same name. The first sight of a
class also stores it by name, which replaces the last-stored-class shortcut.

An object that already has an id comes back without its class index; native
asks for the class only when it has to create a wrapper.

A Java->JS call with an object JS has never seen used to register it from
native code under the isolate lock, so threads calling in with new objects
serialized on that upcall. packageArgs now registers the object itself
(ObjectTable.findOrRegister: lookup and insert under one write lock, so
concurrent registrations agree on one id) and marks the argument fresh;
native wraps a fresh argument without asking Java again. The exact reads
made under the isolate lock now validate against the same StampedLock,
falling back to its read lock, since writers may be on other threads.

If a call fails before its arguments are converted, the objects it
registered are released again rather than staying strong. Where
StampedLock is missing (API < 24) nothing changes: registration stays
under the isolate lock.

processFinalizedBatch took the table's write lock once per id while other
threads may be registering objects before the isolate lock; it now takes it
once per batch. Wrappers collected during a Java->JS call are settled before
the call releases the isolate, and the idle-thread fallback task is delayed a
few milliseconds so a busy runtime no longer wakes its event loop per GC.

With two Java threads calling into JS, every isolate handoff put the waiter
to sleep: V8's mutex spins only briefly, a call holds the isolate for tens of
microseconds, and waking a sleeper took longer than the call itself, so the
isolate sat idle for a wake-up per call. Java->JS calls now pass a per-runtime
gate before v8::Locker whose waiters spin for up to 50us before sleeping.
Nested calls from a thread that already holds the isolate skip it.
Runtime.setAdmissionSpinMicros changes the budget (negative disables the gate)
for benchmarks.

The phone used for these numbers flips between two clock states about 1.6x
apart, which swamps an A/B across launches. Contention rows can now run
several admission spin budgets round by round inside one launch, and the
number of rounds is configurable. The settings live on JniBenchConfig rather
than JniBench: every static added to JniBench is another property on the JS
constructor its static benchmarks are called through, and two more were
enough to slow those rows by ~10 ns.

ConvertJavaArgsToJsArgs returned early for zero arguments before marking the
call converted, so every Java->JS call without arguments ran
ReleaseUnwrappedArgs' slow path: a JEnv lookup, saving and restoring the
pending exception and three array reads, about a third of the native time of
callback.noArgs(). Calls without arguments now pass null arrays, so they make
no array JNI calls at all.

Arguments crossed as an int[] of types and a long[] of values, so native made
three JNI calls per callback (the length and two region copies) and Java
allocated two arrays. The type ids now ride at the end of the long[], one per
byte, and Java passes the count, so native reads everything with a single
GetLongArrayRegion.

…pcall

Every object constructed from JS made two upcalls after the constructor:
makeInstanceStrong, then getUsedMemory for
Isolate::AdjustAmountOfExternalAllocatedMemory. registerConstructedInstance
does both. TryCallGC also skips its compare-and-swap when no GC was
requested.

Package objects exposed each child (java.lang, android.view...) through a
native data property, so every read of `java.lang.Object` ran the C++ getter
once per segment: a std::string conversion, a private-symbol registry
lookup, and a HasPrivate/GetPrivate pair, even after the child had been
resolved. Children are now lazy data properties: V8 calls the getter once
and replaces the property with the value, so later reads are plain
inline-cached loads. The property keeps its attributes (writable,
enumerable, configurable).

Every `new` and every call to an overloaded method built its cache key as a
fresh std::string, copied each argument's type name into another, and
returned the cached entry by value, copying its signature and return-type
strings again. The key is now built in a reused per-thread buffer (copied out
only to insert, since resolving calls into Java and may re-enter), the cache
is a node map whose entries never move, and lookups return a reference to the
entry. MetadataNode::GetName returns a reference instead of a copy.

The per-isolate constants (prototype, toString, valueOf, ...) were created as
ordinary strings, so each property access keyed by one first had to look it
up in the string table. They are now created internalized.

… a fresh key string

Wrapping a Java object created the empty wrapper by calling an API function
as a constructor (a full JS -> C++ transition into an empty callback), copied
the class's method-callback vector just to confirm its constructor template
existed, and set `constructor` with a newly allocated string. The wrapper is
now instantiated from the function template's instance template (the same
object, without entering the callback), GetConstructorFunction returns the
cached function directly, and `constructor` is a cached internalized string.

Without ELF TLS (minSdk < 29) every thread_local access goes through
__emutls_get_address. JEnv's cached env and its pinned flag, and the
runtime's current runtime and id, were separate thread_locals read together
on every JNI entry and runtime lookup; each pair is now one struct.

…lass

…er function each

The first touch of a class installs every static field on its constructor, and
each field got two JS functions (a getter and a setter) built from their own
FunctionTemplates. For android.R.attr that took ~9 ms on the test phone,
android.R.style ~6 ms and android.view.View ~5 ms, per runtime.

A class with more than 64 static fields is now moved to dictionary mode first
(adding properties one by one to a fast-mode object copies its descriptors
each time, which made the native accessors below quadratic) and gets:

- for a final field, a lazy data property: the first read goes through JNI
  and the value replaces the accessor, read-only, so later reads are plain
  property loads (android.R.id.content: 74 ns -> 9 ns);
- for any other field, a native accessor pair instead of two functions.

First access: android.R.attr 8.9 ms -> 1.6 ms, android.R.style 6.2 -> 0.9 ms,
android.view.View 4.9 -> 2.7 ms. Smaller classes keep their accessor
functions. Assigning to a final field of a large class now fails like any
read-only property (a TypeError in strict code) instead of with the runtime's
own error.

A package object gets one lazy property per child, added one by one. On a
fast-mode object each addition copies the descriptors, so android.view
(~800 µs) and android.widget (~950 µs) cost quadratic time on first access.
Packages with more than 64 children now start in dictionary mode, the same
way a class with many static fields does.

V8 internalizes every property name, so a name built from a std::string copy
with kNormal was copied twice more. Names are now created internalized, and
static field names come from a view into the metadata's name table, so
installing a static field no longer reads its name into the entry. The field
accessors read the name on first use instead.

Each method of a class scanned every method of its base class, so a large
class over a large base (TextView over View) did hundreds of thousands of
string comparisons. The base class's methods are now indexed by name once.

When it instantiates a constructible API function, V8 also builds that
function's prototype object, a constructor property on it and an instance
map. A Java class's methods never use them, and a large class has hundreds
of methods (View's first access: 2.0 -> 1.5 ms). Instance methods, field
and property accessors and the runtime's helper functions are now created
with ConstructorBehavior::kThrow. `new view.getAlpha()` already threw (no
Java object behind `this`); it now throws a TypeError.

Class constructors stay constructible, and so do static methods: code like
`new SomeClass.staticFactory()` works today because the factory returns an
object, and published plugins rely on it.

…g it per call

Every Java->JS call copied the method name out of its String with two JNI
calls and internalized it again. Java now gives each name a process-wide
id (a lock-free table keyed on String's cached hash), and each runtime
keeps the V8 string for an id, built the first time it is used.
callback.noArgs: 1,896 -> 1,599 ns; every callback row drops by ~270-300 ns.

…ndex

A Java->JS callback found its target by probing ObjectTable for the
instance's JS object id and boxing its runtime tag into a ConcurrentHashMap
lookup, on every call. Both generators now give bindings an objectId__ns
field next to runtimeTag__ns; initInstance writes it before the tag, and
callJSMethod passes it to native as the id hint (native still checks it).
Runtimes are also indexed by id in an array, and the two AppConfig flags the
call path reads are cached in final fields.

…le with its state

Creating a wrapper for a new object looked its class's MetadataNode up by
name (a mutex and a string hash) and made three allocations to link it. The
per-class-index wrapper cache now also keeps the MetadataNode, and the
v8::Persistent is a member of the weak-callback state instead of a separate
allocation.

GetLinkedJsObjectByJavaObject checked the id's entry and then called
GetJsObjectByJavaObject, which looked the same id up again. Both now hand
the entry they found to JsObjectFor.

Link allocated a JSInstanceInfo, a weak-callback state that duplicated
its id, a V8 External pointing at the JSInstanceInfo, and a node in the
id map. JSInstanceInfo is now part of the state, the wrapper's JsInfo
field holds the object id + 1 instead of an External, and the id map is
a radix tree indexed by id.

Ids are never reused, so a field left on a stale alias resolves to no
state rather than to freed memory, and a leaf or chunk of the tree that
empties is freed unless it is the newest. Leaves (64 ids) and chunks (64
leaves) are small, so a long-lived wrapper keeps at most ~1 KB of the
tree alive. The + 1 keeps the zero V8 stores in an array buffer's
embedder fields from reading as a link.

A wrapper was an empty object from a shared template that then got an
own `constructor` property, a new prototype and a private property
holding a fresh External to its MetadataNode. Each step was a map
transition off one shared map, and the per-class `constructor` values
kept generalizing that map's field, so V8 spent most of a wrapper's
creation migrating and searching maps.

Wrappers now come from the class constructor's instance template, which
starts them on the class's own initial map with the right prototype. The
MetadataNode goes in a new internal field, as one External per class per
runtime shared by all its instances; `new` uses the same field.
Wrappers no longer have an own `constructor`: it resolves through the
prototype to the same function.

Array buffers and views are linked to Java buffers through V8's own two
embedder fields and have no Metadata field; they keep the private
property.

The id side of the table was an open-addressing hash on the id that
doubled and rehashed as it grew. It is now a radix tree indexed by id
(64-id leaves in 64-leaf chunks), holding each entry's value and
identity hash: lookups are three array loads, there is no rehash, and a
leaf or chunk that empties is dropped unless it is the newest, as on
the native side. The identity index is unchanged.

The regular runtime exports everything in the static V8 monolith, so
every call between those functions went through the PLT: 45,008 of the
library's 45,279 jump slots pointed back into the library itself.
-Bsymbolic-functions binds them at link time. Exported functions stay
callable from plugins and data symbols stay interposable. The optimized
runtimes hide V8's internals with a version script and already had only
271 jump slots; this leaves them unchanged.

…mplate

When Java creates an instance of an extended class (an Activity, an
inflated custom view, reflection), its JS object was an empty object from
the shared wrapper template that then got a new prototype and an own
`constructor`. It now comes from the extended class's instance template,
already on its own map with the right prototype, like other wrappers, and
without an own `constructor`. The new benchmark row instantiates an
extended class from Java.