AOT machinery for "full JIT mode"

[bencyoung-Fignum]

As I understand it the AOT compiler does a degree of analysis and partial evaluation of assemblies to produce more optimized static binaries. It seems like some of this (especially things like evaluation of statically called constructors) could be useful for non-AOT assemblies as well. Are there any plans to reuse this analysis information in non-AOT scenarios?

In addition, with the introduction of the "full" interpreter in progress, it seems like it could be possibly to evaluate a larger portion of code at compile time (almost like Zig's comptime support) and then bake this information into the produce artifacts (whether AOT or JIT). Is there any overlap between these interpreters and is it possible that this approach could be followed?

[huoyaoyuan]

As I understand it the AOT compiler does a degree of analysis and partial evaluation of assemblies to produce more optimized static binaries.

This is not the story. JIT is usually more optimized with runtime-calculated values. AOT-exclusive analysis are based on whole program view.

It seems like some of this (especially things like evaluation of statically called constructors) could be useful for non-AOT assemblies as well.

There's no format for storing this. JIT does this sort of optimizations with tiered compilation, and can utilize runtime-loaded values like configurations.

In addition, with the introduction of the "full" interpreter in progress, it seems like it could be possibly to evaluate a larger portion of code at compile time (almost like Zig's comptime support) and then bake this information into the produce artifacts (whether AOT or JIT). Is there any overlap between these interpreters and is it possible that this approach could be followed?

It's not related to interpreter. Evaluate pre-calculated values into ReadyToRun is possible.

[bencyoung-Fignum]

As I understand it the AOT compiler does a degree of analysis and partial evaluation of assemblies to produce more optimized static binaries.

This is not the story. JIT is usually more optimized with runtime-calculated values. AOT-exclusive analysis are based on whole program view.

Yep I understand JIT can be more efficienct due to runtime data, I was wondering if there could be a system that uses both? Static evalution where it can be done, and then runtime when it can't

It seems like some of this (especially things like evaluation of statically called constructors) could be useful for non-AOT assemblies as well.

There's no format for storing this. JIT does this sort of optimizations with tiered compilation, and can utilize runtime-loaded values like configurations.

In addition, with the introduction of the "full" interpreter in progress, it seems like it could be possibly to evaluate a larger portion of code at compile time (almost like Zig's comptime support) and then bake this information into the produce artifacts (whether AOT or JIT). Is there any overlap between these interpreters and is it possible that this approach could be followed?

It's not related to interpreter. Evaluate pre-calculated values into ReadyToRun is possible.

[petrroll]

@bencyoung-Fignum the issue, as I understand it, is that in non-AOT environment you can never know the full program won't change as in that no new assemblies won't be loaded etc. Which makes what you're proposing very limited as most optimisations could simply not be done.

[huoyaoyuan]

Yep I understand JIT can be more efficienct due to runtime data, I was wondering if there could be a system that uses both? Static evalution where it can be done, and then runtime when it can't

In theory, but doesn't exist in reality. AOT and JIT environment load code in totally different manner. JIT environment always loads code lazily. There can exist a JIT environment that uses the same whole-program view of AOT, but it provides major challenge with minor benifit.