Introduce SynchronizedScope to allow heap access from compiler thread.

Introduce SynchronizedScope to allow heap access from compiler thread.

R=mstarzinger@chromium.org

[Yang, 2014-03-20 12:36:31]

On 2014/02/24 10:28:27, Yang wrote:

ping.

[Hannes Payer (out of office), 2014-03-21 12:44:31]

drive-by comment...

https://codereview.chromium.org/177493002/diff/1/src/optimizing-compiler-thre...
File src/optimizing-compiler-thread.cc (right):

https://codereview.chromium.org/177493002/diff/1/src/optimizing-compiler-thre...
src/optimizing-compiler-thread.cc:200: NoBarrier_Store(&loop_switch_,
static_cast<AtomicWord>(loop_switch));
loop_switch_ is accessed with NoBarrier and Acquire/Release operations. I think
we should figure out what mode is required and converge into one mode. I guess
it is Acquire/Release.

[Yang, 2014-03-21 13:01:06]

uploaded new patchset

https://codereview.chromium.org/177493002/diff/1/src/optimizing-compiler-thre...
File src/optimizing-compiler-thread.cc (right):

https://codereview.chromium.org/177493002/diff/1/src/optimizing-compiler-thre...
src/optimizing-compiler-thread.cc:200: NoBarrier_Store(&loop_switch_,
static_cast<AtomicWord>(loop_switch));
On 2014/03/21 12:44:31, Hannes Payer wrote:
> loop_switch_ is accessed with NoBarrier and Acquire/Release operations. I
think
> we should figure out what mode is required and converge into one mode. I guess
> it is Acquire/Release.

For the record, I was thinking the mutex scope would pose a global barrier. But
I guess Acquire/Release wouldn't hurt.

[Michael Starzinger, 2014-03-24 09:21:31]

The implementation is looking OK and I couldn't spot any bugs in the lockstep
synchronization. However we are talking about a synchronization mechanism that
involves four semaphores, one mutex and one atomic variable. This is impossible
to audit. That poses two concrete concerns about this CL:

- In the current form there are neither use-cases nor test-cases for this CL.
How did you test it? Is there a concrete use-case you had in mind for this
mechanism?

- How will all of this work once we move to a system that is based on a job
queue (the thing that Jochen is working on)?

[Yang, 2014-03-24 09:28:28]

On 2014/03/24 09:21:31, Michael Starzinger wrote:
> The implementation is looking OK and I couldn't spot any bugs in the lockstep
> synchronization. However we are talking about a synchronization mechanism that
> involves four semaphores, one mutex and one atomic variable. This is
impossible
> to audit. That poses two concrete concerns about this CL:
> 
> - In the current form there are neither use-cases nor test-cases for this CL.
> How did you test it? Is there a concrete use-case you had in mind for this
> mechanism?
> 
> - How will all of this work once we move to a system that is based on a job
> queue (the thing that Jochen is working on)?

Those are indeed real concerns. I tested this by adding the SynchronizedScope in
a part of the optimizing phase. However, I wasn't able to construct a test case
that would reflect that without intrusively change production code.

I'm not sure how the job queue system is going to handle flushing and stopping,
so I can't tell how well it would fit.

I'm perfectly happy with postponing this until we have to use it at some point.