<p>It is NOT planned for R15B, it is however something which will be needed by the JIT prototype so we will have to implement it while doing that.</p>
<div class="gmail_quote">On Nov 7, 2011 9:48 AM, "Tino Breddin" <<a href="mailto:tino.breddin@googlemail.com">tino.breddin@googlemail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As Paolo mentioned there is a optimization of the code upgrade strategy on the<br>
roadmap for R15B AFAIR. Not only is currently the actual code upgrade only<br>
performed by a single core, but also any other tasks in the system. Meaning<br>
on a well loaded multi-core system all load will need to be handled by that<br>
single core for the time of the upgrade. This might cause the delay you are<br>
seeing.<br>
<br>
T<br>
<br>
On Nov 6, 2011, at 4:33 PM, Paolo Negri wrote:<br>
<br>
> We run an application which runs thousands of long lived processes and<br>
> we see the system blocking on code purge during code updates.<br>
> I remember that Kenneth Lundin at the recent Erlang User Conference<br>
> announced that something related to code loading optimization is in<br>
> the erlang roadmap, hopefully slides will be published soon [1], if I<br>
> remember well the change was related to spreading code purge across<br>
> all the available cores while currently a single core is actually used<br>
> to perform the operation.<br>
><br>
> We also use the trick of compiling data in modules in order to push<br>
> data in the constant pool but we actually have thousands of small<br>
> terms (rendered as one function clause per term) and loading these<br>
> modules doesn't seem to block, but in our case I guess that the<br>
> overall size is much less than 60MB.<br>
><br>
> [1] <a href="http://www.erlang-factory.com/conference/ErlangUserConference2011/speakers/KennethLundin" target="_blank">http://www.erlang-factory.com/conference/ErlangUserConference2011/speakers/KennethLundin</a><br>

><br>
> Paolo<br>
><br>
> On Sun, Nov 6, 2011 at 5:02 AM, Bob Ippolito <<a href="mailto:bob@redivi.com">bob@redivi.com</a>> wrote:<br>
>> Normally just a few hundred, purge isn't the slow part for us and I don't<br>
>> believe that it blocks at all (not that I noticed).<br>
>><br>
>> On Saturday, November 5, 2011, Robert Virding<br>
>> <<a href="mailto:robert.virding@erlang-solutions.com">robert.virding@erlang-solutions.com</a>> wrote:<br>
>>> If you have many processes then code loading can take a noticeable time.<br>
>>> The code server must purge old versions of a module which it does by going<br>
>>> through all processes checking each one if it running the old code and if so<br>
>>> killing it. I don't know if this blocks all the schedulers and if so why,<br>
>>> but it can take a noticeable time to do.<br>
>>><br>
>>> Robert<br>
>>><br>
>>><br>
>>> ________________________________<br>
>>><br>
>>> ETS is no good for our use case, we have ~60MB worth of uncompressed<br>
>>> serialized terms (nested gb_trees mostly) that we need live in a given<br>
>>> request. We traverse it very quickly and end up with a very small list of<br>
>>> terms as the result (essentially a filter on a nested structure). A no-copy<br>
>>> ets would work, but since the work is so short lived and code is tightly<br>
>>> associated to this structure I think that our current solution is<br>
>>> appropriate as long as we can fix the blocking.<br>
>>><br>
>>> "declare constant" may also work, but I think it is more practical to just<br>
>>> make code loading better in the short term (which has other benefits). You<br>
>>> could implement "declare constant" on top of the code loader, we have a<br>
>>> mochiglobal module in mochiweb that basically serves that purpose.<br>
>>><br>
>>> Using a module is a convenient way to give concurrent access to the data<br>
>>> to hundreds of simultaneous processes with minimal serialization.<br>
>>><br>
>>> -bob<br>
>>><br>
>>> On Saturday, November 5, 2011, Björn-Egil Dahlberg<br>
>>> <<a href="mailto:wallentin.dahlberg@gmail.com">wallentin.dahlberg@gmail.com</a>> wrote:<br>
>>>> Yes, it is a simple (and currently only way) to push data to the constant<br>
>>>> pool. You could use ETS instead. It would of course also remove data from<br>
>>>> the heap and reduce GC copy strain but introduce copy on any read.<br>
>>>> Björn Gustavsson talked about introducing a "declare constant" function<br>
>>>> earlier but i don't know if he has done any work on it. The use case was the<br>
>>>> same as for you, pushing lookup structures from gb_trees and gb_sets. But,<br>
>>>> solving code loading would probably be a better prioritization.<br>
>>>> I would like to think that the garbage collector should solve this. Data<br>
>>>> sets which are read only and live are tenured to a generational heap and not<br>
>>>> included in minor gc phases. Putting it in a constant removes it all<br>
>>>> together of course but i would like the garbage collector to identify and<br>
>>>> handle this with generational strategies. The trade off is generational<br>
>>>> heaps linger and may hold dead data longer than necessary.<br>
>>>><br>
>>>><br>
>>>> Den 5 november 2011 21:30 skrev Bob Ippolito <<a href="mailto:bob@redivi.com">bob@redivi.com</a>>:<br>
>>>>><br>
>>>>> We abuse code loading "upgrades" so that we can share memory and reduce<br>
>>>>> GC pressure for large data structures that do not change quickly (once every<br>
>>>>> few minutes). Works great except for all the blocking!<br>
>>>>><br>
>>>>> On Saturday, November 5, 2011, Björn-Egil Dahlberg<br>
>>>>> <<a href="mailto:wallentin.dahlberg@gmail.com">wallentin.dahlberg@gmail.com</a>> wrote:<br>
>>>>>> There is no other locking for code loading than blocking. This is an<br>
>>>>>> optimization of course since locking mechanism overhead is removed from the<br>
>>>>>> equation. Code loading is not used all that often in the normal cases<br>
>>>>>> besides startups and upgrades.<br>
>>>>>> That being said, there are plans to remove this "stop-the-world"<br>
>>>>>> strategy since it is blocking other strategies and optimizations. Also, we<br>
>>>>>> are well aware of that blocking does degrade performance when loading new<br>
>>>>>> modules and does not agree with our concurrency policy.<br>
>>>>>> I think we can lessen the time blocked in the current implementation<br>
>>>>>> but the blocking strategy should (and probably will) be removed. Nothing<br>
>>>>>> planned as of yet though.<br>
>>>>>> Regards,<br>
>>>>>> Björn-Egil<br>
>>>>>><br>
>>>>>> 2011/11/5 Bob Ippolito <<a href="mailto:bob@redivi.com">bob@redivi.com</a>><br>
>>>>>>><br>
>>>>>>> We've found a bottleneck in some of our systems, when we load in<br>
>>>>>>> large<br>
>>>>>>> new modules there is a noticeable pause (1+ seconds) that blocks all<br>
>>>>>>> of the schedulers. It looks like this is because the<br>
>>>>>>> erlang:load_binary/2 BIF blocks SMP before it does anything at all.<br>
>>>>>>><br>
>>>>>>> It would be a big win for us if more of this happened without<br>
>>>>>>> blocking<br>
>>>>>>> the VM, there's a lot of busy work in loading a module that shouldn't<br>
>>>>>>> need any locking. For example, decompressing and decoding the literal<br>
>>>>>>> table is probably where our code spends almost all of its time.<br>
>>>>>>><br>
>>>>>>> There aren't a lot of comments for why it needs to lock the VM,<br>
>>>>>>> especially for the whole of load_binary. Are there any hidden gotchas<br>
>>>>>>> in here that I should know about before giving it a try? I'm unable<br>
>>>>>>> to<br>
>>>>>>> find much where the block is actually necessary, but I am not very<br>
>>><br>
>> _______________________________________________<br>
>> erlang-questions mailing list<br>
>> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
>> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
>><br>
>><br>
><br>
><br>
><br>
> --<br>
> Engineering<br>
> <a href="http://www.wooga.com" target="_blank">http://www.wooga.com</a> | phone <a href="tel:%2B49-30-8962%205058" value="+493089625058">+49-30-8962 5058</a>  | fax <a href="tel:%2B49-30-8964%209064" value="+493089649064">+49-30-8964 9064</a><br>

><br>
> wooga GmbH | Saarbruecker Str. 38 | 10405 Berlin | Germany<br>
> Sitz der Gesellschaft: Berlin; HRB 117846 B<br>
> Registergericht Berlin-Charlottenburg<br>
> Geschaeftsfuehrung: Jens Begemann, Philipp Moeser<br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>