aph at redhat.com
Thu Feb 19 08:14:55 PST 2009
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).
>>> } /* UseCompiler ... */\
>>> 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
>> 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
>>> 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
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.
More information about the zero-dev