i#1114 JIT optimization: core integration

Commit log for first patchset:
---------------
i#1114 JIT optimization: core integration

Complete the integration of the annotation-based optimization
with the core. Leave the JIT fragment accounting itself NYI.
---------------

[Byron, 2016-02-05 20:23:21]

My current implementation of the annotation-based JIT optimization is having
issues with Ion, but I don't think any of the code in this CL is responsible for
those problems.

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

https://codereview.appspot.com/288070043/diff/1/core/jit_opt.c#newcode19
core/jit_opt.c:19: LOG(GLOBAL, LOG_FRAGMENT, 2,
moving all JIT optimization logging to LOG_FRAGMENT

https://codereview.appspot.com/288070043/diff/1/core/jit_opt.c#newcode110
core/jit_opt.c:110: tree->trace_heap = special_heap_init(sizeof(trace_list_t),
true /* lock */,
fix earlier typo

https://codereview.appspot.com/288070043/diff/1/core/jit_opt.c#newcode148
core/jit_opt.c:148: /* Return the first node found at tag, regardless of span.
Compatible with
The tree itself supports multiple nodes at the same tag with different spans.
When the tree becomes a generic data structure, that functionality may be used
for something, so the tag-and-span lookup is kept in the unit test (below).

[bruening, 2016-02-08 21:49:16]

LGTM

https://codereview.appspot.com/288070043/diff/1/core/fragment.c
File core/fragment.c (right):

https://codereview.appspot.com/288070043/diff/1/core/fragment.c#newcode5719
core/fragment.c:5719: 
ok if you think it improves readability

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

https://codereview.appspot.com/288070043/diff/1/core/jit_opt.c#newcode62
core/jit_opt.c:62: # if !(defined (WINDOWS) && defined (X64))
Do we have ARM support?

https://codereview.appspot.com/288070043/diff/1/core/jit_opt.c#newcode149
core/jit_opt.c:149: * basic blocks because multiple instances never occur at the
same tag
They do for thread-private bbs

[Byron, 2016-02-14 01:26:59]

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

https://codereview.appspot.com/288070043/diff/1/core/jit_opt.c#newcode62
core/jit_opt.c:62: # if !(defined (WINDOWS) && defined (X64))
On 2016/02/08 21:49:16, bruening wrote:
> Do we have ARM support?

I'm not quite sure how things work on ARM. Since there is an explicit icache
flush instruction, can we just use the instruction as a trigger for the sub-page
flush? If so, does it require instrumentation (a preamble similar to our
JIT-store preamble), or does the processor provide any kind of interrupt for
notification? I think those questions will determine whether this Valgrind
annotation is useful to the optimization on ARM.

https://codereview.appspot.com/288070043/diff/1/core/jit_opt.c#newcode149
core/jit_opt.c:149: * basic blocks because multiple instances never occur at the
same tag
On 2016/02/08 21:49:16, bruening wrote:
> They do for thread-private bbs

Is it possible for two thread-private bbs (each on a separate thread) to have
the same tag but different lengths? If so, it may be possible to just put all
the unique bbs in the tree, where uniqueness is defined only by start and end
pc.

[bruening, 2016-02-14 04:19:38]

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

https://codereview.appspot.com/288070043/diff/1/core/jit_opt.c#newcode62
core/jit_opt.c:62: # if !(defined (WINDOWS) && defined (X64))
On 2016/02/14 01:26:59, Byron wrote:
> On 2016/02/08 21:49:16, bruening wrote:
> > Do we have ARM support?
> 
> I'm not quite sure how things work on ARM. Since there is an explicit icache
> flush instruction, can we just use the instruction as a trigger for the
sub-page
> flush? If so, does it require instrumentation (a preamble similar to our
> JIT-store preamble), or does the processor provide any kind of interrupt for
> notification? I think those questions will determine whether this Valgrind
> annotation is useful to the optimization on ARM.

I'm asking a narrower question: you're assuming this will work on any non-Win64
platform (your ifdef above does, I mean), but our DR annotation infrastructure
doesn't support ARM today, right?  Will we run into ARM build failures or
anything?

[Byron, 2016-02-14 10:28:56]

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

https://codereview.appspot.com/288070043/diff/1/core/jit_opt.c#newcode62
core/jit_opt.c:62: # if !(defined (WINDOWS) && defined (X64))
On 2016/02/14 04:19:38, bruening wrote:
> On 2016/02/14 01:26:59, Byron wrote:
> > On 2016/02/08 21:49:16, bruening wrote:
> > > Do we have ARM support?
> > 
> > I'm not quite sure how things work on ARM. Since there is an explicit icache
> > flush instruction, can we just use the instruction as a trigger for the
> sub-page
> > flush? If so, does it require instrumentation (a preamble similar to our
> > JIT-store preamble), or does the processor provide any kind of interrupt for
> > notification? I think those questions will determine whether this Valgrind
> > annotation is useful to the optimization on ARM.
> 
> I'm asking a narrower question: you're assuming this will work on any
non-Win64
> platform (your ifdef above does, I mean), but our DR annotation infrastructure
> doesn't support ARM today, right?  Will we run into ARM build failures or
> anything?

Annotations are currently disabled for ARM via cmake, and this entire block is
part of the disabled region (see "#ifdef ANNOTATIONS" above). Should there also
be a "#if" clause for ARM here, in case the usage of ANNOTATIONS changes? 

We actually can support valgrind annotations on ARM (assuming we can borrow
their detection code), so an alternative approach would be to set ANNOTATIONS on
by default for all platforms and just "#ifndef ARM" around the code specific to
DR annotations.

[bruening, 2016-02-19 19:48:06]

On 2016/02/14 10:28:56, Byron wrote:
> https://codereview.appspot.com/288070043/diff/1/core/jit_opt.c
> File core/jit_opt.c (right):
> 
> https://codereview.appspot.com/288070043/diff/1/core/jit_opt.c#newcode62
> core/jit_opt.c:62: # if !(defined (WINDOWS) && defined (X64))
> On 2016/02/14 04:19:38, bruening wrote:
> > On 2016/02/14 01:26:59, Byron wrote:
> > > On 2016/02/08 21:49:16, bruening wrote:
> > > > Do we have ARM support?
> > > 
> > > I'm not quite sure how things work on ARM. Since there is an explicit
icache
> > > flush instruction, can we just use the instruction as a trigger for the
> > sub-page
> > > flush? If so, does it require instrumentation (a preamble similar to our
> > > JIT-store preamble), or does the processor provide any kind of interrupt
for
> > > notification? I think those questions will determine whether this Valgrind
> > > annotation is useful to the optimization on ARM.
> > 
> > I'm asking a narrower question: you're assuming this will work on any
> non-Win64
> > platform (your ifdef above does, I mean), but our DR annotation
infrastructure
> > doesn't support ARM today, right?  Will we run into ARM build failures or
> > anything?
> 
> Annotations are currently disabled for ARM via cmake, and this entire block is
> part of the disabled region (see "#ifdef ANNOTATIONS" above). Should there
also
> be a "#if" clause for ARM here, in case the usage of ANNOTATIONS changes? 
> 
> We actually can support valgrind annotations on ARM (assuming we can borrow
> their detection code), so an alternative approach would be to set ANNOTATIONS
on
> by default for all platforms and just "#ifndef ARM" around the code specific
to
> DR annotations.

OK, just go with the simplest for this CL.