PackageCompiler system image limits: dynamic code inclusion

Dynamic Code Inclusion in System Images

PackageCompiler embeds code into a system image by capturing the state of the Julia session at the time of image creation. Whether dynamic code is preserved depends entirely on when that code is executed relative to the image build process.

Confirmed Behavior

• Macro Expansion: Macros are expanded during the compilation phase. The resulting expanded code is what is stored in the system image; the macro call itself is not preserved as a runtime entity.
• Pre-evaluated Dynamic Code: Code generated via eval or metaprogramming during the precompilation phase is embedded if it results in defined functions, constants, or modified types.
• Runtime-Generated Code: Code designed to be generated after the image is loaded (at runtime) cannot be pre-embedded. This code will still trigger JIT compilation upon execution, incurring the standard latency.

Likely Explanations and Trade-offs

While pre-evaluating dynamic code can eliminate JIT latency for serverless workloads, it introduces specific risks:

• Image Bloat: Including a high volume of pre-evaluated dynamic code increases the system image size and the memory footprint required at startup.
• State Fragility: Code that relies on runtime-specific environment variables or session state during eval may behave unpredictably when restored from a static image.
• Global State: Metaprogramming patterns that modify global module state may not persist unless they are explicitly executed during the build process.

Verification Steps

To determine if your dynamic code is successfully captured, use these scoped checks:

1. Method Inspection: After loading your custom image, run methods(your_dynamic_function). If the function is present without needing to re-run the generation logic, it was captured.
2. Latency Benchmarking: Use the @time macro on the first call of a dynamically generated function. A system image should show significantly lower latency than a standard session.
3. Size Comparison: Compare the size of the resulting .so or .dll file when including versus excluding heavy eval blocks in your build script.

Missing Diagnostic: To provide a more specific recommendation on whether to defer execution, please specify if your dynamic code depends on input data provided at the time of the serverless request.