PackageCompiler system image limits: dynamic code inclusion

Goal and Uncertainty

The aim is to reduce startup latency and CPU usage for low‑traffic Julia workloads by pre‑compiling a custom system image with PackageCompiler. In practice, this strategy is attractive for container or serverless deployments where each invocation incurs a costly JIT phase.

However, the behavior of dynamic code—generated at runtime via eval, macro expansion, or other metaprogramming techniques—remains unclear. The current documentation does not specify whether such code is preserved in the system image, how it is represented, or what impact it has on image size and correctness.

Because many Julia packages rely on runtime code generation, an unresolved decision exists: should the system image include a snapshot of dynamic code, or should it defer execution until runtime? This uncertainty directly affects the viability of PackageCompiler for serverless workloads.

Specific Questions

• Does PackageCompiler embed runtime‑generated code (e.g., from eval or macro expansion) into the system image, and if so, how is it represented?
• What are the observable effects on image size and startup time when dynamic code is included versus excluded?
• Are there recommended patterns or flags to control the inclusion of dynamic code for packages that heavily use metaprogramming?