<div dir="ltr"><div><div><div><div><div><div>Ok.  I tried doing something similar to gdb but was unable to make any headway because they have so many global variables.  It looked more promising with lldb since there were already some locks.<br><br></div>I assume you're talking about check-lldb?<br><a href="https://lldb.llvm.org/test.html">https://lldb.llvm.org/test.html</a><br><br></div>I'll work on getting those to pass reliably.<br><br></div>As for eager vs not, I was just running code that already runs as part of:<br></div>b main<br></div>run<br><br></div>That said, I'm sure all the symbol loading is due to setting a breakpoint on a function name.  Is there really that much value in deferring that?  What if loading the symbols was done in parallel without delaying execution of the debugged program if you didn't have a breakpoint?  Then the impact would be (nearly) invisible to the end user.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 13, 2017 at 5:35 AM, Pavel Labath <span dir="ltr"><<a href="mailto:labath@google.com" target="_blank">labath@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I've have looked at paralelization of the module loading code some time ago, albeit with a slightly different use case in mind. I eventually abandoned it (at least temporarily) because I could not get it to work correctly for all use cases.<div><br></div><div>I do think that doing this is a good idea, but I think it will have to be done with a very steady hand. E.g., if I patch your changes in right now I get about 10 random tests failing on every test suite run, so it's clear that you are introducing a race somewhere.</div><div><br></div><div>We will also need to have a discussion about what kind of work can be done eagerly, as I believe we are trying to a lot of things very lazily (which unfortunately makes efficient paralelization more complicated).</div><div><br></div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On 13 April 2017 at 06:34, Scott Smith via lldb-dev <span dir="ltr"><<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div><div><div><div>The POSIX dynamic loader processes one module at a time.  If you have a lot of shared libraries, each with a lot of symbols, this creates unneeded serialization (despite the use of TaskRunners during symbol loading, there is still quite a bit of serialization when loading a library).<br><br></div>In order to parallelize this, I actually had to do two things.  Neither one makes any difference, only the combination improves performance (I left them as separate patches for clarity):<br><br></div>1. Change the POSIX dynamic loader to fork each module into its own thread.  I didn't use TaskRunner because some of the called functions use TaskRunner, and it isn't recursion safe.  The final modules are added to the list in the original order despite whatever order the threads finish.<br><br></div>2. Change Module::AppendImpl to fire off some expensive work as a separate thread.<br><br></div>These two changes bring startup time down from 36 (assuming the previously mentioned crc changes) seconds to 11.  It doesn't improve efficiency, it just increases parallelism.<br><br></div>
<br></div></div>______________________________<wbr>_________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/lldb-dev</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>