[Feature Request] Bypass 512MB Java Heap Limit via Native Child Process / ADB Wireless Debugging (Like VM Apps)
Hi @tyron12233 and the CodeAssist Team,
First of all, thank you for creating such a phenomenal and ad-free IDE. It is truly the best on-device development tool available right now. However, as projects grow into real-world production apps (using Firebase, ExoPlayer, Material 3, and multiple ViewBinding classes), we are hitting a massive roadblock regarding memory allocation.
The Core Problem: Even on modern devices with 6GB or 8GB of RAM, the JDT Java Compiler (compileJavaDebug) crashes with an Out of Memory (OOM) error because the Android OS strictly enforces a 512MB per-app heap growth limit.
Here is a point-to-point breakdown of the issue and a highly viable architectural solution based on how modern VM apps handle this:
1. The 512MB Heap Bottleneck (OOM Error)
2. Why the Current "Separate Process" Setting Fails
- Issue: Setting "Build in a separate process" and maximizing the "R8 forked-VM heap" to 3072 MB does not solve the
compileJavaDebug crash.
- Reason: Standard Android child processes fork from the Zygote process. Any process born from Zygote automatically inherits the strict 512MB Dalvik/ART heap limit. The IDE gets two separate 512MB buckets, but the compiler needs a single large bucket (e.g., 1GB-2GB) to finish its job.
3. The Solution: Native Child Process via ADB Wireless Debugging
- The Concept: To truly bypass the Zygote heap limit, CodeAssist needs to spawn the compilation toolchain as a standalone native process, rather than a standard Android app component.
- Real-world Example (vPhoneGaga & Virtual Master): Modern Android Virtual Machine (VM) apps face this exact memory restriction. To bypass it, apps like vPhoneGaga and Virtual Master utilize Local ADB (Wireless Debugging) via Developer Options.
- By using Local ADB (pairing on Android 11+), the app can launch a shell daemon process.
- Processes spawned via ADB Shell (or as native linux binaries) are not tied to Zygote's Dalvik heap limits. They can utilize the device's native C/C++ heap and access all available physical RAM (e.g., taking 2GB out of the 6GB available on the device).
- Request: Please investigate implementing an optional "ADB Build Daemon" or "Native JVM Child Process" for heavy compilation tasks. Users could enable Wireless Debugging, grant CodeAssist local ADB access, and the IDE could route the heavy Java compilation/R8 tasks through this independent daemon, completely eliminating the 512MB OOM crash.
If CodeAssist can implement a child process architecture similar to these VM apps, it will officially break the final barrier of on-device development. Developers will be able to build massive, desktop-level production apps directly on their phones. Thank you for your time and incredible work!
[Feature Request] Bypass 512MB Java Heap Limit via Native Child Process / ADB Wireless Debugging (Like VM Apps)
Hi @tyron12233 and the CodeAssist Team,
First of all, thank you for creating such a phenomenal and ad-free IDE. It is truly the best on-device development tool available right now. However, as projects grow into real-world production apps (using Firebase, ExoPlayer, Material 3, and multiple ViewBinding classes), we are hitting a massive roadblock regarding memory allocation.
Here is a point-to-point breakdown of the issue and a highly viable architectural solution based on how modern VM apps handle this:
1. The 512MB Heap Bottleneck (OOM Error)
- Issue: When compiling heavy projects, the build fails specifically during Java compilation with the following log:
- Context: The limit is hardcoded by the OS (536870912 bytes = 512MB). Even though the device has plenty of free RAM, the compiler process is forcefully killed by the system.
FAILED :app:compileJavaDebug: Failed to allocate a 4916848 byte allocation... target footprint 536870912, growth limit 5368709122. Why the Current "Separate Process" Setting Fails
- Issue: Setting "Build in a separate process" and maximizing the "R8 forked-VM heap" to 3072 MB does not solve the
- Reason: Standard Android child processes fork from the Zygote process. Any process born from Zygote automatically inherits the strict 512MB Dalvik/ART heap limit. The IDE gets two separate 512MB buckets, but the compiler needs a single large bucket (e.g., 1GB-2GB) to finish its job.
compileJavaDebugcrash.3. The Solution: Native Child Process via ADB Wireless Debugging
- The Concept: To truly bypass the Zygote heap limit, CodeAssist needs to spawn the compilation toolchain as a standalone native process, rather than a standard Android app component.
- Real-world Example (vPhoneGaga & Virtual Master): Modern Android Virtual Machine (VM) apps face this exact memory restriction. To bypass it, apps like vPhoneGaga and Virtual Master utilize Local ADB (Wireless Debugging) via Developer Options.
- By using Local ADB (pairing on Android 11+), the app can launch a shell daemon process.
- Processes spawned via ADB Shell (or as native linux binaries) are not tied to Zygote's Dalvik heap limits. They can utilize the device's native C/C++ heap and access all available physical RAM (e.g., taking 2GB out of the 6GB available on the device).
- Request: Please investigate implementing an optional "ADB Build Daemon" or "Native JVM Child Process" for heavy compilation tasks. Users could enable Wireless Debugging, grant CodeAssist local ADB access, and the IDE could route the heavy Java compilation/R8 tasks through this independent daemon, completely eliminating the 512MB OOM crash.
If CodeAssist can implement a child process architecture similar to these VM apps, it will officially break the final barrier of on-device development. Developers will be able to build massive, desktop-level production apps directly on their phones. Thank you for your time and incredible work!