Eval of Julia code

One of the hardest parts about learning how the Julia Language runs code is learning how all of the pieces work together to execute a block of code.

Each chunk of code typically makes a trip through many steps with potentially unfamiliar names, such as (in no particular order): flisp, AST, C++, LLVM,eval,typeinf,macroexpand, sysimg (or system image), bootstrapping, compile, parse, execute, JIT, interpret, box, unbox, intrinsic function, and primitive function, before turning into the desired result (hopefully).

Julia Execution

The 10,000 foot view of the whole process is as follows:

1. The user startsjulia.
2. The C functionmain() fromcli/loader_exe.c gets called. This function processes the command line arguments, filling in thejl_options struct and setting the variableARGS. It then initializes Julia (by callingjulia_init ininit.c, which may load a previously compiledsysimg). Finally, it passes off control to Julia by callingBase._start().
3. When_start() takes over control, the subsequent sequence of commands depends on the command line arguments given. For example, if a filename was supplied, it will proceed to execute that file. Otherwise, it will start an interactive REPL.
4. Skipping the details about how the REPL interacts with the user, let's just say the program ends up with a block of code that it wants to run.
5. If the block of code to run is in a file,jl_load(char *filename) gets invoked to load the file andparse it. Each fragment of code is then passed toeval to execute.
6. Each fragment of code (or AST), is handed off toeval() to turn into results.
7. eval() takes each code fragment and tries to run it injl_toplevel_eval_flex().
8. jl_toplevel_eval_flex() decides whether the code is a "toplevel" action (such asusing ormodule), which would be invalid inside a function. If so, it passes off the code to the toplevel interpreter.
9. jl_toplevel_eval_flex() thenexpands the code to eliminate any macros and to "lower" the AST to make it simpler to execute.
10. jl_toplevel_eval_flex() then uses some simple heuristics to decide whether to JIT compile the AST or to interpret it directly.
11. The bulk of the work to interpret code is handled byeval ininterpreter.c.
12. If instead, the code is compiled, the bulk of the work is handled bycodegen.cpp. Whenever a Julia function is called for the first time with a given set of argument types,type inference will be run on that function. This information is used by thecodegen step to generate faster code.
13. Eventually, the user quits the REPL, or the end of the program is reached, and the_start() method returns.
14. Just before exiting,main() callsjl_atexit_hook(exit_code). This callsBase._atexit() (which calls any functions registered toatexit() inside Julia). Then it callsjl_gc_run_all_finalizers(). Finally, it gracefully cleans up alllibuv handles and waits for them to flush and close.

Parsing

The Julia parser is a small lisp program written in femtolisp, the source-code for which is distributed inside Julia insrc/flisp.

The interface functions for this are primarily defined injlfrontend.scm. The code inast.c handles this handoff on the Julia side.

The other relevant files at this stage arejulia-parser.scm, which handles tokenizing Julia code and turning it into an AST, andjulia-syntax.scm, which handles transforming complex AST representations into simpler, "lowered" AST representations which are more suitable for analysis and execution.

If you want to test the parser without re-building Julia in its entirety, you can run the frontend on its own as follows:

$ cd src$ flisp/flisp> (load "jlfrontend.scm")> (jl-parse-file "<filename>")

Macro Expansion

Wheneval() encounters a macro, it expands that AST node before attempting to evaluate the expression. Macro expansion involves a handoff fromeval() (in Julia), to the parser functionjl_macroexpand() (written inflisp) to the Julia macro itself (written in - what else - Julia) viafl_invoke_julia_macro(), and back.

Typically, macro expansion is invoked as a first step during a call toMeta.lower()/jl_expand(), although it can also be invoked directly by a call tomacroexpand()/jl_macroexpand().

Type Inference

Type inference is implemented in Julia bytypeinf() incompiler/typeinfer.jl. Type inference is the process of examining a Julia function and determining bounds for the types of each of its variables, as well as bounds on the type of the return value from the function. This enables many future optimizations, such as unboxing of known immutable values, and compile-time hoisting of various run-time operations such as computing field offsets and function pointers. Type inference may also include other steps such as constant propagation and inlining.

JIT Code Generation

Codegen is the process of turning a Julia AST into native machine code.

The JIT environment is initialized by an early call tojl_init_codegen incodegen.cpp.

On demand, a Julia method is converted into a native function by the functionemit_function(jl_method_instance_t*). (note, when using the MCJIT (in LLVM v3.4+), each function must be JIT into a new module.) This function recursively callsemit_expr() until the entire function has been emitted.

Much of the remaining bulk of this file is devoted to various manual optimizations of specific code patterns. For example,emit_known_call() knows how to inline many of the primitive functions (defined inbuiltins.c) for various combinations of argument types.

Other parts of codegen are handled by various helper files:

• debuginfo.cpp

  Handles backtraces for JIT functions

• ccall.cpp

  Handles the ccall and llvmcall FFI, along with variousabi_*.cpp files

• intrinsics.cpp

  Handles the emission of various low-level intrinsic functions

System Image

The system image is a precompiled archive of a set of Julia files. Thesys.ji file distributed with Julia is one such system image, generated by executing the filesysimg.jl, and serializing the resulting environment (including Types, Functions, Modules, and all other defined values) into a file. Therefore, it contains a frozen version of theMain,Core, andBase modules (and whatever else was in the environment at the end of bootstrapping). This serializer/deserializer is implemented byjl_save_system_image/jl_restore_system_image instaticdata.c.

If there is no sysimg file (jl_options.image_file == NULL), this also implies that--build was given on the command line, so the final result should be a new sysimg file. During Julia initialization, minimalCore andMain modules are created. Then a file namedboot.jl is evaluated from the current directory. Julia then evaluates any file given as a command line argument until it reaches the end. Finally, it saves the resulting environment to a "sysimg" file for use as a starting point for a future Julia run.