i#1114 JIT optimization: thread handling

Commit log for first patchset:
---------------
i#1114 JIT optimization: thread handling

Implements thread handling for the JIT optimization,
including waiting for linking threads, notifying threads
during JIT fragment unlinking (NYI), and iterating the
set of active threads to remove fragments (NYI).
---------------

[Byron, 2016-01-08 03:23:03]

This CL covers all thread handling for the optimization. If the CL is too big, I
can cut the LOC roughly in half (though this CL will be needed for reference).

https://codereview.appspot.com/282090043/diff/1/core/globals.h
File core/globals.h (right):

https://codereview.appspot.com/282090043/diff/1/core/globals.h#newcode548
core/globals.h:548: extern mutex_t jitopt_lock;
This is just needed for an assert in fragment.c (NYI until the next CL)

https://codereview.appspot.com/282090043/diff/1/core/jit_opt.c
File core/jit_opt.c (right):

https://codereview.appspot.com/282090043/diff/1/core/jit_opt.c#newcode16
core/jit_opt.c:16: LOG(GLOBAL, LOG_FRAGMENT, 2,
I'm thinking everything here can be logged on LOG_FRAGMENT.

https://codereview.appspot.com/282090043/diff/1/core/jit_opt.c#newcode542
core/jit_opt.c:542: } else if (walk->parent == tree->nil) {
Fixed a memory leak here.

https://codereview.appspot.com/282090043/diff/1/core/jit_opt.c#newcode571
core/jit_opt.c:571: uint version; /* object version (incremented on every thread
entry and exit */
missing ")" is fixed in my local

https://codereview.appspot.com/282090043/diff/1/core/jit_opt.c#newcode898
core/jit_opt.c:898: unit_test_clear_span(app_pc start, app_pc end)
Can't really test the deployed version of this anymore, now that it integrates
with other modules that are out of unit-test scope.

https://codereview.appspot.com/282090043/diff/1/core/utils.h
File core/utils.h (right):

https://codereview.appspot.com/282090043/diff/1/core/utils.h#newcode356
core/utils.h:356: LOCK_RANK(jitopt_lock),   /* < linking_lock, >
thread_initexit_lock */
I think the only reason to have this ranked so close to outermost is that the
fix for high fan-in (NYI) needs to access the fragment tree while the
linking_lock is held. I recently made a new version of the fix that may be able
to avoid this--and we may never commit that fix anyway, since high fan-in
doesn't have a huge impact (and the fix is messy).

[Byron, 2016-01-08 21:31:16]

Commit log for latest patchset:
---------------
i#1114 JIT optimization: thread handling

Implements thread handling for the JIT optimization,
including waiting for linking threads, notifying threads
during JIT fragment unlinking (NYI), and iterating the
set of active threads to remove fragments (NYI).

Review-URL: https://codereview.appspot.com/282090043
---------------

[Byron, 2016-01-08 21:38:04]

Making some minor changes to the thread negotiation blocks around the fragment
removal loop (no semantic changes here).

https://codereview.appspot.com/282090043/diff/20001/core/jit_opt.c
File core/jit_opt.c (right):

https://codereview.appspot.com/282090043/diff/20001/core/jit_opt.c#newcode685
core/jit_opt.c:685: mutex_unlock(&pt->linking_lock);
an obvious simplification

https://codereview.appspot.com/282090043/diff/20001/core/jit_opt.c#newcode700
core/jit_opt.c:700: else if (pt->soon_to_be_linking)
Removed my original comment, since it was based on a misunderstanding of a
comment in similar code.

https://codereview.appspot.com/282090043/diff/20001/core/jit_opt.c#newcode740
core/jit_opt.c:740: mutex_lock(&jitopt_lock);
I moved this inside the thread negotiation blocks because it's ok for other
threads to change the tree until we get started with removals.

https://codereview.appspot.com/282090043/diff/20001/core/jit_opt.c#newcode894
core/jit_opt.c:894: /* Inserts the specified number of new random nodes. */
just grouping functions more logically

[bruening, 2016-01-14 19:42:34]

DR already has thread coordination for flushing and for suspension.  Could you
write a paragraph (in a comment in the code might be best) describing why we
need to add this new thread synch scheme?

[Byron, 2016-01-15 01:56:14]

On 2016/01/14 19:42:34, bruening wrote:
> DR already has thread coordination for flushing and for suspension.  Could you
> write a paragraph (in a comment in the code might be best) describing why we
> need to add this new thread synch scheme?

It may be possible to share thread handling code with the existing flush
mechanism. During the JIT project I didn't understand the code well enough to
even try it (though I considered it), but now I could probably work through an
attempt in an hour or two. This would also avoid duplicating special cases, like
the Windows-only conditions for flushing fragments from a thread that is at a
syscall (which the optimization doesn't handle, since we only implemented on
Linux). 

The current problem with code sharing is that the threadwise unlink API
{flush_fragments_synch_unlink_priv(), flush_fragments_unlink_shared(),
flush_fragments_end_synch()} directly calls vm_area_unlink_fragments() to remove
the whole vmarea. The solution might be as simple as splitting:

    flush_fragments_synch_unlink_priv()

into two functions:

    flush_fragments_synch_priv()        /* usher all threads outside of linking
state */
    flush_fragments_synch_unlink_priv() /* delegate to
flush_fragments_synch_priv(), then remove vmarea */

The JIT flush would just call flush_fragments_synch_priv(), then remove
fragments in its own way (subpage granularity), and finally
flush_fragments_end_synch(). Let me know if that's the preferable approach.

[bruening, 2016-01-15 15:40:17]

On Thu, Jan 14, 2016 at 8:56 PM, <byron.c.hawkins@gmail.com> wrote:

> On 2016/01/14 19:42:34, bruening wrote:
>
>> DR already has thread coordination for flushing and for suspension.
>>
> Could you
>
>> write a paragraph (in a comment in the code might be best) describing
>>
> why we
>
>> need to add this new thread synch scheme?
>>
>
> It may be possible to share thread handling code with the existing flush
> mechanism. During the JIT project I didn't understand the code well
> enough to even try it (though I considered it), but now I could probably
> work through an attempt in an hour or two. This would also avoid
> duplicating special cases, like the Windows-only conditions for flushing
> fragments from a thread that is at a syscall (which the optimization
> doesn't handle, since we only implemented on Linux).
>
> The current problem with code sharing is that the threadwise unlink API
> {flush_fragments_synch_unlink_priv(), flush_fragments_unlink_shared(),
> flush_fragments_end_synch()} directly calls vm_area_unlink_fragments()
> to remove the whole vmarea. The solution might be as simple as
> splitting:
>
>     flush_fragments_synch_unlink_priv()
>
> into two functions:
>
>     flush_fragments_synch_priv()        /* usher all threads outside of
> linking state */
>     flush_fragments_synch_unlink_priv() /* delegate to
> flush_fragments_synch_priv(), then remove vmarea */
>
> The JIT flush would just call flush_fragments_synch_priv(), then remove
> fragments in its own way (subpage granularity), and finally
> flush_fragments_end_synch(). Let me know if that's the preferable
> approach.
>

That sounds good to me, leveraging the existing mechanisms rather than
adding a separate parallel scheme.