 |  |  | Anomaly 2 |
To identify which HPM events correlate with the drop in IPC before each garbage collection, we used the Performance Explorer to select for each group of HPM events a representative set of warehouse trace records between two garbage collections and to compute the set's average for all HPM events (Total).6 From this representative set, we used the Performance Explorer to pick the subset of trace records that represented the IPC drop (Drop) and computed its average for all HPM events. After these two computations, we identified the HPM events whose average values differed the most between Total and Drop. Table * presents our results. The first column identifies the HPM events. The HPM event values are normalized by dividing by cycles, except for STCX_FAIL, which is normalized by the number of STCX attempts. The second column presents the values for all trace records in the set (Total), the third column presents the values for the subset of trace records after IPC drops (Drop), and the final column presents how Drop's average changes as a percentage of Total's average. As can be seen, the IPC degraded by 6.4%, while there is a substantial increase (178-423%) in the percentage of the identified HPM events.
The set of events in Table * is eclectic.
The HV_CYC (the processor is executing in hypervisor mode) and
EE_OFF (the MSR EE bit is off) events
specify the cycles spent in the kernel.
The GRP_DISP_BLK_SB_CYC (dispatch is blocked by scoreboard),
LSU_SRQ_SYNC_CYC (sync is in store request queue), and
STCX_FAIL (a stcx instruction fails) events all have to do with synchronization.
The
LSU_LRQ_FULL_CYC event indicates that the load request queue is full and stalls
dispatch.
Both the HV_CYC and EE_OFF events indicated increased kernel activity, and the difference in HV_CYC/CYC percentages accounts for just over 10% of all the cycles. The trace records for pseudojbb reflect both user and kernel mode execution; that is, the HPM counters continued counting when control enters the kernel. To determine if there was some underlying pathological Jikes RVM behavior that was causing increased kernel activity, we used the unix truss command to trace kernel calls. Other than yield, _nsleep, thread_waitact, and calls to the kernel HPM routines, there were no unusual kernel calls or increase in call activity that would explain the performance drop.
There is some indication that the IPC drop may be due to effective to real address translation (ERAT). The 128 entry IERAT and 128 entry DERAT are a cache for the 1024 entry TLB. We are investigating this hypothesis more thoroughly.
This anomaly illustrates the difficulty with determining performance anomalies with HPM information only. Deep microarchitectural, OS, and JVM knowledge is required to augment the HPM information.
| | | Anomaly 2 |