Hello,
Here are some critical bugs I found on GEMS EETM. I made sure that the
solutions to these bugs made EETM more stable by running the GEMS simulation on
STAMP benchmarks.
I thought HTM researchers might be interested about these.
Bug #1:
Not including the thread id to tm_trap_handler function call.
Related Files and Code:
// microbenchmarks/transactional/common/transaction.c
void tm_trap_handler(int threadID){
...
}
...
void transaction_manager_stub(int dummy){
...
BEGIN_ESCAPE
asm volatile( \
"call %1\n" \
"mov %%g2, %%O0\n" \
"mov %%g3, %0\n" \
:"=r"(restart)
:"r"(&tm_trap_handler)
:"%o0", "%o7"
);
...
}
Reason:
The GCC inline assembly used on transaction_manager_stub() function
does not
correctly include the thread id (register g2 sent from GEMS) value to
tm_trap_handler function.
Solution:
The second assembly line of "mov %%g2, %%o0\n" should be
moved before the "call %1\n" line.
Bug #2:
Software abort trap handler unrolling the trap handler's stack space.
Reason:
Eager VM logs thread's stack space and it becomes trouble when log
unrolling takes place on abort trap handler's
own stack space. It will overwrite itself with log data and trap
handler will act almost randomly.
Randomly writing other log's data or using random memory section as
log may happen.
Steps leading to an error:
1. A transaction enters a function and writes some data to heap
and stack.
2. The data gets written to the stack, heap and the log.
3. The transaction exits the function and stack pointer
shrinks.
4. The transaction gets aborted due to conflict in heap area.
5. The software abort trap handler starts log unrolling from
the shrunken stack pointer.
6. The undo log space and the stack space for the trap handler
collides.
7. Trap handler unrolls the log and overwrites itself.
8. Corruption in trap handler's stack space cause random log
unrolling.
9. System goes haywire.
Solution:
1. Take stack pointer just before starting trap handling.
2. Ignore undo log when the target data is pointed at the trap
handler's stack area.
We can figure this out if the target address
is between the current and old stack pointer.
Related Files and Code:
// ruby/microbenchmarks/transactional/common/transaction.c
void tm_unroll_log_entry(unsigned int* entry){
int k;
unsigned int *address = (unsigned int *) (*(entry+16)
& ADDRESS_MASK);
for (k = 0; k < 16; k++){
// NOTE: This should be the place for
checking writing to itself.
unsigned int data = "" + k);
*address = data;
address++;
}
}
Bug #3:
Not aborting the transaction when there is a conflict with non-TM or
escape action.
Reason:
Due to 16 words cache granularity there is a possiblity of false
conflict between a transaction
and non-transactional code. Current GEMS version just allow non-TM
code to read the transactionally isolated line.
Steps leading to an error:
Step 1: thread 1's transaction trA writes x
Step 2: thread 2's non-transactional code reads y.
Unfortunately word x
and word y shares the same cache line.
Step 3: thread 1 allows thread 2's read request.
Step 4: thread 2 starts a new transaction trB.
Step 5: trB reads line x, but does not report to L2 because it's in
shared state.
It gets a simple line
hit. Therefore trA is unaware of conflict.
Step 6: trA aborts
Step 7: trB writes z = x + y and commits. word z is on a different
cache.
Solution:
When a non-TM read/write request comes and there is a hit on
write-set perfect filter to a TM thread,
the transaction searches from the front for old log value and send it
to the requestor instead
of sending the value from L1 cache.
After sending out the old value, the transaction removes the
conflicted address from
the undo log and the write set. The transaction aborts.
Note: This sending out the old value and removing the conflicted
address from the undo log
and the write set is important
because we don't want to overwrite later what non-TM
might have written at the time of
conflict. Also note that this sending out the old
log value has been practiced on
STM compilers, too.
Related Files and Code:
// ruby/protocols/MESI_CMP_filter_directory-L1cache.sm
transition(M, Fwd_GETX, I)
{
d_sendDataToRequestor;
l_popRequestQueue;
}
transition(M, Inv, I)
{
f_sendDataToL2;
l_popRequestQueue;
}
- Byong-Wu Chong
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}