[erlang-questions] Frequency of module reloading and the constant pool
Thu Sep 21 00:10:56 CEST 2017
Sorry, I meant Adam not Lukas!
- Edmond -
On Thursday, 21 September 2017 at 08:09 Edmond Begumisa <ebegumisa@REDACTED> wrote:
Thanks for the tips Lukas.
That process killing issue did actually bite me in the ar*e a few seemingly random times. Luckily, for my use-case, the processes depending on the controlled hot-swapping are known so I was able to mitigate against this by keeping track of the which versions each process knows about.
- Edmond -
On Tuesday, 19 September 2017 at 19:13 Adam Lindberg wrote:
Cost wise I'm not sure, but I would advice you to benchmark for your use case.
Operations wise the most common problem you'll see with module reloads is crashed processes. Erlang only keeps two versions of a module in memory at the same time. If you have processes lingering in the old code when reloading yet another version, those processes will get killed.
> On 16 Sep 2017, at 23:57, Edmond Begumisa wrote:
> On Sun, 17 Sep 2017 03:39:50 +1000, Edmond Begumisa wrote:
>> Hello all,
>> (Not new here--just haven't posted in a while!)
>> I'm using merl to dynamically generate and regenerate modules at runtime that make use of the ERTS constant pool in order to efficiently avail data to all processes. I'm aware that this technique is known amongst more experienced Erlangers for situations where the data is updated infrequently (e.g. sharing global configuration parameters).
>> The question I'm investigating is how frequent is "infrequent" w.r.t reloading of modules? I'm not entirely sure about the costs involved when (re)loading a module so I've got no idea where to start in order to measure the impact on the emulator. Could anybody with sufficient knowledge of emulator internals point me in the right direction?
> To clarify: When measuring whether or not I'm hot-code swapping too frequently, what are the negative signs to look for? What does the emulator actually do when swapping out code w.r.t potentially disruptive/costly operations like locking, GC, etc which could negatively impact scheduling, memory and responsiveness of the system?
> I'm trying to figure out when the best time to reload a dynamically generated module/group of modules is and how frequently I should allow reloading to occur.
> - Edmond -
>> Thanks in advance.
>> - Edmond -
>>  The more exotic use-cases for use/abuse of the constant pool and module reloading I'm looking into are to do with caching and incremental computation.
> Using Opera's mail client: http://www.opera.com/mail/
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions