backedge checks

[Andrew Haley]

Edward Nevill wrote:

> Apologies for the legal notices that appeared in my previous emails. I am now doing this
> from my home machine over a wet piece of string. Email address is now either ed at camswl.com
> or ed at starksfield.org (both resolve to the same machine).

OK.

>>>           INCR_INVOCATION_COUNT;\
>>>           SAFEPOINT;\
>>>         }\
>>>       }  /* UseCompiler ... */\
>>>       INCR_INVOCATION_COUNT;\
>>>       SAFEPOINT;\
>>>     }
>>>
>>>
>>> This macro is invoked in every branch (although the body is only
>>> executed on backwards branches).
>>>
>>> Firstly, is it just me, or does it do INCR_INVOCATION_COUNT; SAFEPOINT
>>> twice on every backwards branch. Surely a mistake?
>> It looks like that to me.
> 
> OK. Can someone with committal rights remove the first instance.

>>> Secondly, can someone tell me under what circumstances in zero
>>> UseCompiler would ever be true (and no, it doesn't resolve to a
>>> constant.
>> This stuff is AFAIK used to decide when to compile a method with Shark.
> 
> OK. So Shark is using the bytecode interpreter rather than the template interpreter?
> Is this correct Gary?

> In that case it is even more important we do something about the dire performance.
> 
> Regardless, when we are building zero (interpreted) this should be defined to be constant
> false. At the moment it is a global.

In purely interpreted mode, yes.

> This is no different from the case where 'notice_safepoints' actually updates the table.
> The VM is still not synchronised, and we have to either wait until control returns or
> until someone else calls notice_safepoints. Remember the state is not set to synchronised
> until all threads have synchronised.
> 
> On exit, before calling ignore_safepoints the VM is places in an unsynchronised state.
> Therefore it doesn't matter whether we call the safe or unsafe branch handler. The
> safe branch handler simply does an extra check on 'is_synchronizing' which returns false.
> 
> The only thing that could really ruin your day is if word write is not atomic, and I think
> there is a lot of code that will break is word write is not atomic.

Yes, right.  This sounds like it'll work.

I admit that this sounds wrong, when it could be done simply by switching
a single pointer, but a word read from memory to get the address of
the table on every bytecode isn't such a great idea either.

>>> Finally, can someone enlighten me as to the purpose of
>>> INCR_INVOCATION_COUNT, if we can get rid of that we could get rid of
>> all
>>> backedge checks.
>> Surely the compile broker uses that count.
> 
> Yes, is the compiler the only thing that is using this? Is it used for profiling, or ...
> 
> We need to move to a world where we are not doing all these redundant checks with all the
> attendant crud when the check trips to a world where we have a simple VM which just
> handles the common default case.
> 
> If someone does require all this crud then we simply direct them to
> 
> BytecodeInterpreter::run_with_all_unnecessary_crud(..)

Yes, but it would surely be nice to have a decent fast interpreter when
we're running with Shark.  There ought to be some reasonable compromise.

Andrew.