APT Wiki | Jamaica / Thu2Mar06

Speculation and Transactional Memory subgroup meeting. IT413, 13:30, Thu 2 Mar 2006.

Present

Ian Watson, Gavin Brown, Matt Horsnell, Jisheng Zhao, Andrew Dinn, Kostas Nikas, Ian Rogers, Jeremy Singer

Agenda

Identifying Group Theme

Discussion

(iw) What are we trying to achieve in this group? Presumably a spectrum of h/w and s/w.

At the h/w end, we need support for speculation. Which flavour? TLS, Transactional mem, a hybrid?

(mh) TLS preferrable, since there are more possibilities for automatic (h/w controlled) speculation. Less dependence on s/w. Also fewer changes required in Jikes RVM.

(ad) There would be a large overhead for retargetting Jikes RVM to support TCC for instance. RVM requires globally visible side-effects within transactions, which is tricky.

(iw) Flat view of memory, where updates must be broadcast globally, is a mistaken approach.

s/w support and compilation - would be similar for transactional memory as for TLS. Two areas of research here. (1) Jisheng - speculative loop parallelization. (2) Gavin+Jeremy - speculative method level parallelization.

(mh) Discussion with Jisheng on communicating speculative values across token ring. Parent thread can forward register values to speculative child thread. Would not require too much implementation effort. Need a different kind of token, with thread-id and register value. 2 new instructions, WAIT_SPECULATIVE_TOKEN and EMIT_SPECULATIVE_TOKEN.

(ad) Problems with garbage collection here. Speculative child thread has to be running on processor when token goes past on ring. So it must be in a busy-wait loop that can't be interrupted! Also, would need buffering for these extra tokens, possible ack token to return to parent thread. If we implemented this technique, it would allow suspend/resume data flow between threads, could use for loop pipelining. Todd Mowry stampede project has implemented h/w support for this kind of buffering for speculative threads awaiting values.

The existing Jamaica WAIT primitive is useless since it would sleep through GC.

(ir) Clarification - it is not our intention to make this approach the main speculative mechanism.

(ad) but it would be good for loop pipelininig, for both speculative and non-speculative loop bodies!

(iw) concerned that we might be implementing complex mechanisms that are only for special cases. Would this effort slow-down overall research progress?

(mh) Explanation of directory structure in shared L2 cache, containing info about all the L1 caches. Can mark speculative data reads / writes. On cache overflow, can flush speculative data from L1 caches to L2 cache, still store speculatively using L2 directory tags.

(ir) how about gated store buffers?

(mh) All buffers will overflow eventually.

(ir) Also overhead of content-addressable mem.

(jz) What about GC? Simplest solution would be to kill speculative threads on GC.

(iw) Mechanism for dealing with speculative threads being squashed. Will this be h/w or s/w?

(mh) could be either. Cache can automatically flush speculative lines. Or exception handler could deal with this in s/w?

(kn) Thinking about implementing cache coherence protocols based on speculative mechanisms.

(iw) next meeting: Gavin can report on speculative method-level parallelization, in his paper.