Re: [Gems-users] retry hack in ATMTP/Rock

[Daniel Nussbaum - Sun Microsystems - Burlington United States <dan.nussbaum@xxxxxxx>]

>
> Date: Sun, 27 Jul 2008 01:27:55 -0400
> From: salil pant <floydian27@xxxxxxxxx>
>

Hi Salil.

>
> I am a little confused about the retry hack being used in the
> ATMTP/Rock simulator.  This is what I have understood so far: you
> catch exceptions within Transactions and detect their type.
>

In ATMTP, instructions that would cause synchronous exceptions of any
kind don't -- instead, they cause the transaction to abort and
execution resumes at the fail address.

>
> Inside the Core_Exception hap, however, you change the PC to point
> to a new location which contains the RETRY instruction.  What does
> this do?
>

This is a hack (hence the name "retry hack").  The problem is that by
the time we know that the instruction is going to cause an exception,
the simulation has proceeded too far to tell it "no, I don't want that
instruction to execute".  Unfortunately, traps modify a lot of state
in the processor that would be difficult for us to unmodify correctly.
Instead, the trap hack causes makes use of the processor's own "return
from trap" mechanism (i.e., the retry instruction) to unroll most of
the processor state, and we then arrange to roll back the rest of the
processor state and resume execution at the fail address.

>
> Does the code inside the exception handler execute or not?
>

Not.

>
> what is the use of the retry?
>

It causes an immediate return-from-trap sequence to happen.

>
> I ask this mainly because we abort when the exception completes
> anyway and we change the PC back to the beginning of the
> transaction.
>
> Why not just let the execution handler finish and then simply
> rollback using a checkpoint and switch the PC back to the start of
> the transaction?  What am I missing here?
>

In general, the trap handler may perform side effects that our
transaction-abort mechanism doesn't know how to (or can't) roll back.
For example, if the trap is a TLB miss, the trap handler might even
have to go so far as to read from the disk.

http://research.sun.com/scalable/pubs/TRANSACT2008-ATMTP.pdf contains
more details about this mechanism -- see section 3.1.2, "Synchronous
Exceptions" paragraph.

Does this help?

Dan Nussbaum

>
> salil
>