<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 02/16/2016 11:20 PM, Pierre Fenoll
wrote:<br>
</div>
<blockquote
cite="mid:B7B5580B-39FB-4DC8-B9C1-1F7049919A6A@gmail.com"
type="cite">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div>Release inlining could be a compiler option only activated
when desired. </div>
<div>It would require no additional semantics to the language,
only the additional lantency associated with swapping inlined
code times the number of modules, though we may be able to go
sublinear here. <br>
</div>
</blockquote>
If you are unable to update a system with separate components (and
instead need to update everything to make sure the system is able to
function correctly), the difference between that and simply
restarting the operating system process becomes negligible, unless
you consider the extra complexity when not simply restarting the
operating system process. There are other details like keeping
ports open that could work when changing everything, or it might
not.<br>
<br>
<blockquote
cite="mid:B7B5580B-39FB-4DC8-B9C1-1F7049919A6A@gmail.com"
type="cite">
<div><br>
On 17 Feb 2016, at 06:53, Michael Truog <<a
moz-do-not-send="true" href="mailto:mjtruog@gmail.com">mjtruog@gmail.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 02/15/2016 07:38 AM, Pierre
Fenoll wrote:<br>
</div>
<blockquote
cite="mid:CAMmfOZusrzkOhzBj03PALBq-yq_Jg3L8L5116=0PxKeb4oVEnQ@mail.gmail.com"
type="cite">
<div dir="ltr">This is surely a very naive idea on how to
one day get cross-module inlining
<div>or at least enlarge the range of possibilities for
the JIT.
<div><br>
</div>
<div>A lot of inlining is impossible due to the
possibility to hot-swap code.</div>
<div>But what about in the context of a release?</div>
</div>
</div>
</blockquote>
Inlining isn't impossible due to the possibility to hot-swap
code. However, inlining is simpler when modules are grouped
together into a blob you can call a release.<br>
<br>
Inlining could rely on the inlined version of a function and a
non-inlined version of the function where the inlined version
of a function contains references to all the versions of
various modules that it depends on. Any hot-code loading
should then create a ripple effect, changing the rest of the
system in a way not limited to the module being updated, which
makes the module update process error-prone (if only due to
the difference in latency with a module being indirectly
changed due to a function inline) when abandoning the concept
of isolation.<br>
<br>
Tracking the dependencies that can be cyclic should be a
complexity that is at least linear, so as you add more inlined
functions, the latency with a module update grows in at least
a linear way. That means a module update could cause longer
downtime due to a module update when many functions are
inlined, where the downtime is worse as more functions get
inlined, and that is only when considering the inlining in the
old version of the module. When inlining is used, you have
the tendency to group modules together, as you have described,
to try to make sure everything is inlined as a group, so you
preserve the lower latency function calls. If all the modules
that are inlined together are updated together, you can
minimize any problems dealing with non-inlined versions of the
functions due to dependencies on old modules, but that would
make the module update process longer, and would avoid the
isolation a single module update currently provides.<br>
<br>
Forcing inlined modules to be updated in a big group might be
nice with application versions, if you say functions can only
be inlined within a single OTP application and not across OTP
application boundaries, but as the documentation does show,
changing an OTP application during runtime is ad-hoc since it
depends on what you are doing to your supervisor(s) and
everything else, while a single module update is a simple
atomic change between two module versions.<br>
<br>
It is a really nice property of a module update, with the
current situation in Erlang, where you know only the module
will be changing when you update the source code. Keeping
that isolation of change to make sure potential errors have a
definite and clear scope is important. The problem of dealing
with dependencies due to inlining is why I suggested using a
templating concept instead, since that achieves inlining
without making module updates error-prone.<br>
<br>
<blockquote
cite="mid:CAMmfOZusrzkOhzBj03PALBq-yq_Jg3L8L5116=0PxKeb4oVEnQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div><br>
</div>
<div>When creating a release (or updating an old one),</div>
<div>the compiler/relx/whatever is generating the
release has a clear and finite scope</div>
</div>
<div>of all the code that will be shipped and run.</div>
<div>Maybe not a clear idea of extra dependencies or
resources,</div>
<div>but at least all the Erlang code should be there.</div>
<div>Then a compiler would be able to do supercompilation,
agressive inlining, …</div>
<div><br>
</div>
<div>I was thinking that we could then get a release that
resembles an executable</div>
<div>and if we can link external dependencies (OpenSSL, …)</div>
<div>we would then have a somewhat standalone binary that
kind of works like escripts.</div>
<div><br>
</div>
<div>Is my reasoning right?</div>
<div>Where am I on the scale from extremely naive all the
way up to ROK?</div>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div class="gmail_signature">
<div dir="ltr">
<div>
<div><br>
</div>
<div>Cheers,</div>
<div>-- </div>
<div>Pierre Fenoll</div>
</div>
<div><br>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">On 7 December 2015 at 05:45,
Richard A. O'Keefe <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class=""><br>
On 3/12/2015, at 8:11 pm, Michael Truog <<a
moz-do-not-send="true"
href="mailto:mjtruog@gmail.com">mjtruog@gmail.com</a>>
wrote:<br>
> If we had header files that were only allowed
to contain functions and<br>
> types that we called "template files" for lack
of a better name<br>
> (ideally, they would have their own export
statements to help<br>
> distinguish between private functions/types and
the interface for modules<br>
> to use)<br>
> AND<br>
> we had the include files (and template files)
versioned within the beam<br>
> output (to address the untracked dependency
problem).<br>
><br>
> Wouldn't that approach be preferable when
compared<br>
> to trying to manage the module dependency graph
during a<br>
> runtime code upgrades? Why would the "template
files" approach<br>
> not be sufficient?<br>
<br>
</span>These are the differences I can see between
'template files'<br>
and 'import_static modules'.<br>
<br>
(1) 'template files' would not be modules.<br>
Having their own export directives would make them<br>
modul*ar*, but they could not use 'fun M:F/A' to
refer<br>
to their own functions, having no M they could
use.<br>
<br>
This does not seem like a good thing.<br>
<br>
(2) Headers can be nested. If 'template files' were
to be<br>
like headers, this would create nested scopes for
top<br>
level functions, and the possibility of multiple<br>
distinct functions with the same name and arity
and<br>
in some sense "in" the very same module.<br>
<br>
I don't see that as an insuperable problem, but
it's a<br>
very big change to the language in order to avoid
what<br>
is really not likely to be a practical problem.<br>
<br>
(3) 'template files' are copied into the including
module,<br>
which allows different modules to have included<br>
different versions of a 'template file'.<br>
<br>
Like headers, this DOES NOT SOLVE the dependency
and<br>
version skew problems, IT CREATES THOSE PROBLEMS.<br>
<br>
So with 'template files', either you have precisely
the<br>
same problems you have with headers plus a whole lot
of<br>
extra complexity, or you have to track dependencies
anyway.<br>
<br>
If we can take a step away from Erlang,<br>
we can see that we have a fundamental problem.<br>
<br>
Resource A is prepared from foundations x and c.<br>
Resource B is prepared from foundations y and c.<br>
Resources A and B have to "fit together" in some
fashion.<br>
Common foundation c has something to do with how that<br>
fitting together works.<br>
<br>
c is revised to c'.<br>
A is re-prepared to A'.<br>
If B were re-prepared, B' and A' would be compatible,<br>
just as B and A were compatible.<br>
But B and A' are not compatible.<br>
<br>
As far as I can see, there are three general ways to<br>
deal with this kind of problem.<br>
<br>
1. Detection. When you try to use A' and B together,<br>
detect that they were prepared from c' and c and<br>
refuse to allow this use.<br>
<br>
This requires dependency tracking.<br>
<br>
2. Prevention. When c is revised to c', use
dependencies<br>
forward and queue A and B for rebuilding.<br>
<br>
This requires dependency tracking.<br>
<br>
3. Avoidance. Make the preparation step fairly
trivial<br>
so that whenever A (B) makes references to c, the<br>
latest version of c is used.<br>
<br>
In programming language terms, this is not even
lazy<br>
evaluation, it's call-by-name. It's the way
Erlang<br>
currently handles remote calls. (More or less.)<br>
<br>
As a rule of thumb, early binding is the route to<br>
efficiency (and early error detection), late
binding<br>
is the route to flexibility (and late error
detection).<br>
The performance cost may be anywhere between
slight and<br>
scary depending on the application.<br>
<br>
3'. It is only necessary to provide the *appearance*
of late<br>
binding. I have a faint and probably unreliable
memory<br>
that the SPITBOL implementation of SNOBOL4 could
generate<br>
"optimised" code but could back it out and
recompile it<br>
when the assumptions it had made turned out to be
wrong.<br>
<br>
Amongst other things, this requires the system to
keep<br>
track of this-depends-on-that at run time, so it's
still<br>
dependency tracking, but it need not be visible to
the<br>
programmer.<br>
<br>
What might be noticeable would be a performance
blip as<br>
loading c' caused everything that had been
run-time compiled<br>
against c to be de-optimised. TANSTAAFL.<br>
<div class="HOEnZb">
<div class="h5"><br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a moz-do-not-send="true"
href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a moz-do-not-send="true"
href="http://erlang.org/mailman/listinfo/erlang-questions"
rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
erlang-questions mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
</blockquote>
<br>
</div>
</blockquote>
</blockquote>
<br>
</body>
</html>