You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit fef13a1
Browse filesBrowse the repository at this point in the historyBrowse files
perf: cheaper object construction; drop markingMode full (#2093)
* test: benchmark the object lifecycle phases and many live wrappers
Splits a wrapped object's cost into allocation (kept alive), release through
a V8 GC and the Java GC that follows, for JS-constructed, JS-extended and
Java-returned objects; and times an object return with 50k live wrappers.
* perf: trim per-construction work in RegisterInstance
- EncodeSignature formatted the argument count through a std::stringstream
on every constructor and dynamic method resolution; it now appends
std::to_string into a reserved buffer.
- The instance's class is the global ref ResolveClass already returned from
the class cache, so the second FindClass(fullClassName) lookup is gone.
- JsArgConverter skips parsing the signature of a zero-argument constructor.
- makeInstanceStrong skips storeClass, which takes two locks, when the
previous registration stored the same class.
* refactor: remove the markingMode "full" machinery
Only markingMode "none" is supported. "full" was already non-functional:
its weak callback queued wrappers for processing that no longer existed, so
they were revived forever.
- ObjectManager always arms the finalizer path; the full-mode weak callback,
its GC bookkeeping, the batch DirectBuffer plumbing and the unused
declarations behind it are gone, as are DirectBuffer itself and the Java
makeInstanceWeak(ByteBuffer)/checkWeakObjectAreAlive/getMarkingModeOrdinal.
- AppConfig drops the key (native config indices shift accordingly) and logs
a warning when an app still sets markingMode to anything but "none".
- The __markingMode global is gone; testGC.js no longer gates on it, so its
specs now run (they pass under the finalizer path).
* refactor: pass the native startup options by name
initNativeScript received AppConfig's whole value array and the native side
read five entries by KnownKeys ordinal, so removing or reordering a key
silently shifted them (and read past the end under CheckJNI). The five
values are now explicit initNativeScript parameters, gathered into a
Runtime::StartupOptions on the native side.
* test: keep the 50k wrappers pinned while their benchmark is timed
0 commit comments