[PR #1931] [MERGED] perf(ghidra): compile bundle activator with bridge scripts #4919

Closed
opened 2026-10-31 00:56:46 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/1931
Author: @N0zoM1z0
Created: 10/11/2026
Status: ✅ Merged
Merged: 10/11/2026
Merged by: @morluto

Base: main ← Head: perf/ghidra-bundle-activator-1065


📝 Commits (1)

  • fa7a012 perf(ghidra): compile bundle activator with bridge scripts

📊 Changes

4 files changed (+40 additions, -2 deletions)

View changed files

➕ bridge/ghidra/ReaGhidraBundleActivator.java (+14 -0)
📝 package.json (+1 -0)
📝 scripts/verify-packaged-ghidra-windows.mjs (+18 -1)
📝 scripts/verify-packed-bridge.mjs (+7 -1)

📄 Description

Ghidra opens a second Java compiler and file manager to build a generated OSGi activator after compiling REA's bridge scripts. The Windows JFR investigation for #1065 caught this extra pass during bridge preparation.

Ship the equivalent no-op BundleActivator with the bridge sources so Ghidra selects it from the first compilation. The packaged Windows verifier checks the actual compiled class and Bundle-Activator manifest entry, and rejects a generated activator. The normal package check also verifies that the new source is shipped.

Validation:

  • Full check:fast with serial task scheduling, build:cached, normal npm pack, and the actual packed-bridge verifier passed.
  • Installed package on native Windows, Ghidra 12.1.4 / JDK 21 / SDK 2.3.1: selected class and manifest verified; two distinct functions analyzed with separate Evidence IDs and text/structured parity; input unchanged, empty runtime after close, no observed owned descendants.
  • Native Windows x86 PE32 DLL, same installed artifact without JFR: return 42, caller +1, and the call edge verified; two function analyses, selected activator and cleanup passed. The explicitly reset first query took 248.452 s; native family peak was 878.55 MiB.
  • Full-stage JFR export retained 8,471 CPU/native events, including recorded truncated stacks. Flameox checked the bridge-phase weights against the preserved stacks. No bridge-phase sample contains buildDefaultActivator; the actual manifest/class checks establish that REA supplies the activator.

The profiled first query took 190.114 s; native family peak was 958.44 MiB with a 512 MiB JVM heap. Filesystem cache state was uncontrolled, so the overall timing difference is not a controlled speedup measurement. The default 60 s SDK deadline and large-target memory work remain open.

Refs #1065.


🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/1931 **Author:** [@N0zoM1z0](https://github.com/N0zoM1z0) **Created:** 10/11/2026 **Status:** ✅ Merged **Merged:** 10/11/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `perf/ghidra-bundle-activator-1065` --- ### 📝 Commits (1) - [`fa7a012`](https://github.com/morluto/rea/commit/fa7a012e994b9655aa6d455e350c91c3943090fa) perf(ghidra): compile bundle activator with bridge scripts ### 📊 Changes **4 files changed** (+40 additions, -2 deletions) <details> <summary>View changed files</summary> ➕ `bridge/ghidra/ReaGhidraBundleActivator.java` (+14 -0) 📝 `package.json` (+1 -0) 📝 `scripts/verify-packaged-ghidra-windows.mjs` (+18 -1) 📝 `scripts/verify-packed-bridge.mjs` (+7 -1) </details> ### 📄 Description Ghidra opens a second Java compiler and file manager to build a generated OSGi activator after compiling REA's bridge scripts. The Windows JFR investigation for #1065 caught this extra pass during bridge preparation. Ship the equivalent no-op `BundleActivator` with the bridge sources so Ghidra selects it from the first compilation. The packaged Windows verifier checks the actual compiled class and `Bundle-Activator` manifest entry, and rejects a generated activator. The normal package check also verifies that the new source is shipped. Validation: - Full `check:fast` with serial task scheduling, `build:cached`, normal `npm pack`, and the actual packed-bridge verifier passed. - Installed package on native Windows, Ghidra 12.1.4 / JDK 21 / SDK 2.3.1: selected class and manifest verified; two distinct functions analyzed with separate Evidence IDs and text/structured parity; input unchanged, empty runtime after close, no observed owned descendants. - Native Windows x86 PE32 DLL, same installed artifact without JFR: return 42, caller +1, and the call edge verified; two function analyses, selected activator and cleanup passed. The explicitly reset first query took 248.452 s; native family peak was 878.55 MiB. - Full-stage JFR export retained 8,471 CPU/native events, including recorded truncated stacks. Flameox checked the bridge-phase weights against the preserved stacks. No bridge-phase sample contains `buildDefaultActivator`; the actual manifest/class checks establish that REA supplies the activator. The profiled first query took 190.114 s; native family peak was 958.44 MiB with a 512 MiB JVM heap. Filesystem cache state was uncontrolled, so the overall timing difference is not a controlled speedup measurement. The default 60 s SDK deadline and large-target memory work remain open. Refs #1065. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
bsakaguchi 2026-10-31 00:56:46 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#4919
No description provided.