<p>It's too early to say anything yet, we will have to wait and see what happens. It might possibly maybe happen somewhere between now and the big crunch. </p>
<div class="gmail_quote">On Nov 7, 2011 6:23 PM, "Anthony Molinaro" <<a href="mailto:anthonym@alumni.caltech.edu">anthonym@alumni.caltech.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Neat! A JIT prototype.  What is the story there?  Is that actively being<br>
worked on somewhere by someone?  Can anyone provide details or an idea of<br>
when we might see it?<br>
<br>
Thanks,<br>
<br>
-Anthony<br>
<br>
On Mon, Nov 07, 2011 at 01:12:38PM +0100, Lukas Larsson wrote:<br>
> It is NOT planned for R15B, it is however something which will be needed by<br>
> the JIT prototype so we will have to implement it while doing that.<br>
> On Nov 7, 2011 9:48 AM, "Tino Breddin" <<a href="mailto:tino.breddin@googlemail.com">tino.breddin@googlemail.com</a>> wrote:<br>
><br>
> > As Paolo mentioned there is a optimization of the code upgrade strategy on<br>
> > 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]<br>
> > <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<br>
> > 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<br>
> > time.<br>
> > >>> The code server must purge old versions of a module which it does by<br>
> > going<br>
> > >>> through all processes checking each one if it running the old code and<br>
> > if so<br>
> > >>> killing it. I don't know if this blocks all the schedulers and if so<br>
> > 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<br>
> > of<br>
> > >>> terms as the result (essentially a filter on a nested structure). A<br>
> > no-copy<br>
> > >>> ets would work, but since the work is so short lived and code is<br>
> > 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<br>
> > just<br>
> > >>> make code loading better in the short term (which has other benefits).<br>
> > 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<br>
> > 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<br>
> > constant<br>
> > >>>> pool. You could use ETS instead. It would of course also remove data<br>
> > 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"<br>
> > function<br>
> > >>>> earlier but i don't know if he has done any work on it. The use case<br>
> > was the<br>
> > >>>> same as for you, pushing lookup structures from gb_trees and gb_sets.<br>
> > But,<br>
> > >>>> solving code loading would probably be a better prioritization.<br>
> > >>>> I would like to think that the garbage collector should solve this.<br>
> > Data<br>
> > >>>> sets which are read only and live are tenured to a generational heap<br>
> > 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<br>
> > and<br>
> > >>>> handle this with generational strategies. The trade off is<br>
> > 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<br>
> > reduce<br>
> > >>>>> GC pressure for large data structures that do not change quickly<br>
> > (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<br>
> > from the<br>
> > >>>>>> equation. Code loading is not used all that often in the normal<br>
> > 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.<br>
> > Also, we<br>
> > >>>>>> are well aware of that blocking does degrade performance when<br>
> > 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.<br>
> > 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<br>
> > 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<br>
> > shouldn't<br>
> > >>>>>>> need any locking. For example, decompressing and decoding the<br>
> > 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<br>
> > 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>
> ><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>
Anthony Molinaro                           <<a href="mailto:anthonym@alumni.caltech.edu">anthonym@alumni.caltech.edu</a>><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>