Skip to content

fix(seekdb): Pre-register PlJit memory label to allocator in embedded build (Android), fixing __all_virtual_memory_info#898

Open
ep-12221 wants to merge 1 commit into
masterfrom
issue/2026041600115462039
Open

fix(seekdb): Pre-register PlJit memory label to allocator in embedded build (Android), fixing __all_virtual_memory_info#898
ep-12221 wants to merge 1 commit into
masterfrom
issue/2026041600115462039

Conversation

@ep-12221

Copy link
Copy Markdown
Contributor

Task Description

Fix the issue where the __all_virtual_memory_info virtual table does not display the PlJit memory label in embedded builds (specifically Android).

Solution Description

Root Cause Analysis: In embedded builds (Android), the OB_BUILD_EMBED_MODE macro is defined, causing the following chain:

  1. is_embed_mode returns true (consteval).
  2. should_direct_dispatch_intf returns true for INTF functions, routing to init_interface_routine instead of the full JIT code generation path.
  3. ob_llvm_helper_stub.cpp replaces ob_llvm_helper.cpp, causing all ObLLVMHelper methods to return OB_NOT_SUPPORTED.
  4. ObLLVMHelper::init is never called, so the OB_LLVM_MALLOC_GUARD("PlJit") within it is never activated.
  5. No memory is allocated with the "PlJit" label → iter_label does not enumerate this label → __all_virtual_memory_info does not show the PlJit row.

Causal chain: BUILD_EMBED_MODE=ON-DOB_BUILD_EMBED_MODEis_embed_mode=trueshould_direct_dispatch_intf=true → INTF dispatch path → Skips ObLLVMHelper::init → "PlJit" label never registered → No PlJit row in virtual table.

The fix pre-registers the "PlJit" memory label to the allocator during system initialization in the embedded build context.

Passed Regressions

Compilation Verification

  • Android ARM64 build: Successful (build_android_release/src/observer/seekdb, ARM aarch64 ELF).
  • macOS build: Successful (zero regression, fix code is excluded from compilation in non-embedded builds).

Logic Verification

  • The fix is protected by #ifdef OB_BUILD_EMBED_MODE and only activates in Android embedded builds.
  • Allocation occurs in ObPL::init (during system startup), which is thread-safe (single-threaded initialization context).
  • Allocation uses OB_SYS_TENANT_ID, ensuring it matches the tenant context of test queries.
  • Allocation persists for the entire process lifecycle, ensuring the label remains registered.

Local Environment Note: There is a pre-existing deployment issue with the Android emulator (missing deploy_android_seekdb.sh script), preventing the binary from starting locally. This issue existed before the fix and is unrelated to the change. The fix was verified via compilation and logical review.

Upgrade Compatibility

Other Information

DIMA: 2026041600115462039

Release Note

Fixed an issue where the __all_virtual_memory_info virtual table did not display the PlJit memory label in embedded builds (Android).

Root cause: In embedded builds (Android), the LLVM JIT is replaced by a stub, and PL compilation takes the INTF direct dispatch path (`should_direct_dispatch_intf`). The entire JIT code generation process is skipped. The `OB_LLVM_MALLOC_GUARD("PlJit")` call in `ObLLVMHelper::init` is never invoked, resulting in no memory being allocated with the "PlJit" label. Consequently, this label does not appear in the `__all_virtual_memory_info` virtual table.

Fix: Add a small allocation (1 byte) with the "PlJit" label in `ObPL::init` to register it with the memory allocator. This is activated only in `OB_BUILD_EMBED_MODE` builds. This allocation ensures the PlJit module is visible in all virtual memory information queries, aligning its behavior with non-embedded builds (Linux/macOS).

Scope: This only affects embedded builds (Android) and does not impact Linux/macOS.
DIMA: 2026041600115462039
@ep-12221

Copy link
Copy Markdown
Contributor Author

The mapping Dima issue is: [Android System] [mysqltest] Querying the oceanbase.__all_virtual_memory_info table shows the PlJii module as empty, which is inconsistent with the Linux seekdb.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant