Contexts are the unit of lifetime-management within the API: objects have their lifetime bounded by the context they are created within, and cleanup of such objects is done for you when the context is released.
This function acquires a new gcc_jit_context * instance, which is independent of any others that may be present within this process.
This function releases all resources associated with the given context. Both the context itself and all of its gcc_jit_object * instances are cleaned up. It should be called exactly once on a given context.
It is invalid to use the context or any of its “contextual” objects after calling this.
gcc_jit_context_release (ctxt);
Given an existing JIT context, create a child context.
The child inherits a copy of all option-settings from the parent.
The child can reference objects created within the parent, but not vice-versa.
The lifetime of the child context must be bounded by that of the parent: you should release a child context before releasing the parent context.
If you use a function from a parent context within a child context, you have to compile the parent context before you can compile the child context, and the gcc_jit_result of the parent context must outlive the gcc_jit_result of the child context.
This allows caching of shared initializations. For example, you could create types and declarations of global functions in a parent context once within a process, and then create child contexts whenever a function or loop becomes hot. Each such child context can be used for JIT-compiling just one function or loop, but can reference types and helper functions created within the parent context.
Contexts can be arbitrarily nested, provided the above rules are followed, but it’s probably not worth going above 2 or 3 levels, and there will likely be a performance hit for such nesting.