* [Caml-list] empty mli for executable
@ 2013-10-03 16:50 Milan Stanojević
2013-10-03 17:45 ` Alain Frisch
0 siblings, 1 reply; 4+ messages in thread
From: Milan Stanojević @ 2013-10-03 16:50 UTC (permalink / raw)
To: Caml List
ocaml compiler executables have empty mlis with the following comment
(*
this "empty" file is here to speed up garbage collection in ocamlopt.opt
*)
Can someone explain this in more detail?
How does empty interface lead to faster gc-ing?
Thanks,
Milan
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Caml-list] empty mli for executable
2013-10-03 16:50 [Caml-list] empty mli for executable Milan Stanojević
@ 2013-10-03 17:45 ` Alain Frisch
2013-10-03 18:42 ` Milan Stanojević
0 siblings, 1 reply; 4+ messages in thread
From: Alain Frisch @ 2013-10-03 17:45 UTC (permalink / raw)
To: Milan Stanojević, Caml List
On 10/03/2013 06:50 PM, Milan Stanojević wrote:
> ocaml compiler executables have empty mlis with the following comment
> (*
> this "empty" file is here to speed up garbage collection in ocamlopt.opt
> *)
>
> Can someone explain this in more detail?
> How does empty interface lead to faster gc-ing?
The empty interface implies that toplevel values computed by those
modules don't need to be stored in the global symbol slots. Those slots
are roots for the GC and are thus scanned every time it runs. The fewer
global symbols, the quicker the GC will be. Well, this is the theory,
I'd be really surprised if this materialized in a speed up which can be
observed.
Having an empty interface has a much more practical interest, in
general: it allows the compiler to detect unused declarations in the
implementation (if the corresponding warnings are enabled), and thus to
reduce code rot.
-- Alain
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Caml-list] empty mli for executable
2013-10-03 17:45 ` Alain Frisch
@ 2013-10-03 18:42 ` Milan Stanojević
2013-10-03 20:52 ` Alain Frisch
0 siblings, 1 reply; 4+ messages in thread
From: Milan Stanojević @ 2013-10-03 18:42 UTC (permalink / raw)
To: Alain Frisch; +Cc: Caml List
> The empty interface implies that toplevel values computed by those modules
> don't need to be stored in the global symbol slots. Those slots are roots
> for the GC and are thus scanned every time it runs. The fewer global
> symbols, the quicker the GC will be. Well, this is the theory, I'd be
> really surprised if this materialized in a speed up which can be observed.
Thanks, Alain.
Just one question about this. Let's say I have a toplevel value in my
executable and an empty mli. How is this toplevel value then retained?
Is it part of some other root set ?
> Having an empty interface has a much more practical interest, in general: it
> allows the compiler to detect unused declarations in the implementation (if
> the corresponding warnings are enabled), and thus to reduce code rot.
Yes, I've been doing this, it is a very useful feature of the compiler.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Caml-list] empty mli for executable
2013-10-03 18:42 ` Milan Stanojević
@ 2013-10-03 20:52 ` Alain Frisch
0 siblings, 0 replies; 4+ messages in thread
From: Alain Frisch @ 2013-10-03 20:52 UTC (permalink / raw)
To: Milan Stanojević; +Cc: Caml List
On 10/3/2013 8:42 PM, Milan Stanojević wrote:
> Thanks, Alain.
> Just one question about this. Let's say I have a toplevel value in my
> executable and an empty mli. How is this toplevel value then retained?
> Is it part of some other root set ?
Well, actually, after double-checking, it appears that in native code,
the non-exported values are still stored in the global record
corresponding to the unit. See this comment in translmod.ml:
Identifiers that are not exported are assigned positions at the
end of the block (beyond the positions of all exported idents).
This is just one possible compilation strategy, designed to reduce
pressure on registers (and it invalidates my explanation). Another one
would be to simply consider those value as local variables (in
registers, maybe spilled to the stack).
The current strategy has the effect that a non-exported toplevel value
is never reclaimed by the GC, even if it is no longer accessible (this
is not the case in bytecode).
Alain
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-10-03 20:52 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-10-03 16:50 [Caml-list] empty mli for executable Milan Stanojević
2013-10-03 17:45 ` Alain Frisch
2013-10-03 18:42 ` Milan Stanojević
2013-10-03 20:52 ` Alain Frisch
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox