|Anonymous | Login | Signup for a new account||2017-05-26 07:31 CEST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005664||OCaml||runtime system and C interface||public||2012-06-27 15:54||2016-12-08 10:16|
|Priority||high||Severity||feature||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0005664: Wish: caml_unregister_frametable|
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 Files||ocaml-frametable.patch [^] (4,244 bytes) 2012-07-17 16:36 [Show Content]|
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.
|caml_unregister_frametable is now included in the runtime (caml/stack.h).|
|2012-06-27 15:54||gerd||New Issue|
|2012-07-17 14:30||doligez||Priority||normal => high|
|2012-07-17 14:30||doligez||Status||new => acknowledged|
|2012-07-17 16:36||gerd||File Added: ocaml-frametable.patch|
|2012-07-17 16:42||gerd||Note Added: 0007765|
|2013-12-05 15:59||doligez||Tag Attached: patch|
|2016-12-08 10:16||shinwell||Note Added: 0016827|
|2016-12-08 10:16||shinwell||Status||acknowledged => resolved|
|2016-12-08 10:16||shinwell||Resolution||open => fixed|
|2016-12-08 10:16||shinwell||Assigned To||=> shinwell|
|2017-02-23 16:43||doligez||Category||OCaml runtime system => runtime system|
|2017-03-03 17:45||doligez||Category||runtime system => runtime system and C interface|
|Copyright © 2000 - 2011 MantisBT Group|