Bump-pointer method caching for embedded Java processors

Abstract

Caching of complete methods has been suggested to simplify the determination of the worst-case execution time (WCET) in the presence of a memory hierarchy [9]. While this previous approach limits possible cache misses to method invocations and returns, it still assumes a conventional blocked organization of the cache memory. This paper proposes and evaluates a new approach organizing the cached methods within a linked list while tag matching is limited to a sliding window of at most three methods over this linked list. The main advantages of this approach are the avoidance of low block utilization by small methods through bump-pointer space allocation and a further simplification of the WCET analysis by an easy miss prediction based solely on call stack information available locally.

Cross‐profiling for Java processors

“…A method cache is also integrated in the embedded Java processor SHAP [23] and considered in jamuth [32] as a time-predictable caching solution. 1 With a method cache, only invoke and return bytecodes can result in a cache miss.…”

Cache-aware cross-profiling for java processors

“…A method cache is also integrated in the embedded Java processor SHAP [23] and considered in jamuth [32] as a time-predictable caching solution.…”

WCET-Based Comparison of an Instruction Scratchpad and a Method Cache

“…This is necessary in order to prevent memory fragmentation. The M$ has been implemented as part of the JOP CPU [14], as part of the SHAP CPU [30], as part of Patmos [25], and independently by Metzlaff et al [31]. The M$ hardware is more complex than the SPM hardware, as the search functionality is usually implemented in hardware.…”