You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 5664 Reporter: gerd Assigned to:@mshinwell Status: resolved (set by @mshinwell on 2016-12-08T09:16:49Z) Resolution: fixed Priority: high Severity: feature Version: 4.00.0+beta2/+rc1 Category: runtime system and C interface Tags: patch Monitored by:@whitequark meyer @Chris00
Bug description
Hi,
I'd like to see a function caml_unregister_frametable that removes a frame table that was previously registered.
Background: I'm currently experimenting with a JIT compiler where the input is an algebraic expression and the output machine code. The resulting code can be called as OCaml function, and the code mainly calls other OCaml functions. A very simple generator, and it works well so far, with a little drawback: one cannot deallocate the generated code anymore, because there is no way to unregister the also generated frametable from the OCaml runtime.
caml_unregister_frametable would just have to remove the table from the linked list "frametables", and create the hash tables again. Simple to do, and I will happily provide a patch if this wish is granted.
Additional information
Of course, I know I depend on the internal calling conventions of OCaml, and the JIT compiler will always be very specific to the OCaml version.
The intention of the JIT compiler is to remove interpretation overhead, especially the cost of random indirect jumps. Even with the minimalistic approach I'm currently following, I see already speedups.
Why the need for deallocation of generated code? The compiler is also used in server context where the expressions to compile come from a client.
I'm doing this right now for a company, but there is hope that I can release the compiler, hopefully driving the discussion.
Attached you find a patch: it does not only add caml_unregister_frametable, but also improves the management of the hash table. If new frametables are registered, the hash table is not always rebuilt, but entries are directly added so far the headroom allows this. I observed that the rebuilding of the hash table can take a considerable amount of time (several hundred milliseconds, even for a moderately-sized program), so this should be better avoided if possible. If no frametables are dynamically added, the code behaves as before.
The patch got some testing, but not yet ultimately much.
Original bug ID: 5664
Reporter: gerd
Assigned to: @mshinwell
Status: resolved (set by @mshinwell on 2016-12-08T09:16:49Z)
Resolution: fixed
Priority: high
Severity: feature
Version: 4.00.0+beta2/+rc1
Category: runtime system and C interface
Tags: patch
Monitored by: @whitequark meyer @Chris00
Bug description
Hi,
I'd like to see a function caml_unregister_frametable that removes a frame table that was previously registered.
Background: I'm currently experimenting with a JIT compiler where the input is an algebraic expression and the output machine code. The resulting code can be called as OCaml function, and the code mainly calls other OCaml functions. A very simple generator, and it works well so far, with a little drawback: one cannot deallocate the generated code anymore, because there is no way to unregister the also generated frametable from the OCaml runtime.
caml_unregister_frametable would just have to remove the table from the linked list "frametables", and create the hash tables again. Simple to do, and I will happily provide a patch if this wish is granted.
Additional information
Of course, I know I depend on the internal calling conventions of OCaml, and the JIT compiler will always be very specific to the OCaml version.
The intention of the JIT compiler is to remove interpretation overhead, especially the cost of random indirect jumps. Even with the minimalistic approach I'm currently following, I see already speedups.
Why the need for deallocation of generated code? The compiler is also used in server context where the expressions to compile come from a client.
I'm doing this right now for a company, but there is hope that I can release the compiler, hopefully driving the discussion.
File attachments
The text was updated successfully, but these errors were encountered: