200 likes | 319 Views
This presentation explores the challenges and methodologies of Worst-Case Execution Time (WCET) analysis specifically for Java processors, featuring insights from Martin Schoeberl from TU Vienna and Rasmus Pedersen from CBS, Denmark. It discusses the motivation for WCET analysis in real-time systems, addresses the issues with static WCET analysis, and introduces the Java processor JOP designed to simplify and enhance analyzability. The results highlight the performance and features of JOP, focusing on method caching, execution time considerations, and future improvements for integration into real-time architectures.
E N D
WCET Analysis for a Java Processor Martin Schoeberl TU Vienna, Austria Rasmus Pedersen CBS, Denmark
Outline • Motivation • WCET analysis • The Java processor JOP • Results • Conclusion, future work • Demo Martin Schoeberl – WCET Analysis for a Java Processor
Motivation • Schedule analysis • For (hard) real-time • Execution time numbers needed • Static WCET analysis • No measurements! • Can not guarantee the WC • Still used Martin Schoeberl – WCET Analysis for a Java Processor
Issues with static WCET Analysis • Why is WCET Analysis so seldom used? • High-level part is easy • Low-level is the hard part • Instruction timing • Caches • Advanced, speculative processors Martin Schoeberl – WCET Analysis for a Java Processor
Static WCET Analysis • Mature research • High-level based in ILP • Construct CFG • Add execution time to BB • Build ILP equations: • Sum of BB texe will be maximized • Frequency of in-edges = out-edges • Add loop constraints Martin Schoeberl – WCET Analysis for a Java Processor
Low-level WCET Analysis • Execution time of basic blocks • Sum of instruction timing? • Not in modern CPUs • What about memory access? • Instruction cache • Instruction prefetch • Data cache • Very hard for general purpose CPUs Martin Schoeberl – WCET Analysis for a Java Processor
The Proposed Solution • Build a processor to simplify WCET Analysis • Avoid non analyzable features • Find better solutions • Java processor JOP • Built from ground up for WCET • FPGA implementation (small) • Not slow on average Martin Schoeberl – WCET Analysis for a Java Processor
JOP Features • A RISC stack machine • 4 stage pipeline • No dependencies • No shared state (e.g. memory) • Stack cache • Method cache Martin Schoeberl – WCET Analysis for a Java Processor
Size Martin Schoeberl – WCET Analysis for a Java Processor
Performance Martin Schoeberl – WCET Analysis for a Java Processor
Low-level Timing • Bytecode execution time known • Analysis of microcode (DATE’06) • No dependencies • Documented Martin Schoeberl – WCET Analysis for a Java Processor
Memory Access • Assume SRAM • Constant access time (rws and wws) • Access time partially hidden: • Method cache load: • Partially hidden Martin Schoeberl – WCET Analysis for a Java Processor
Method Cache • Full method loaded • Misses only on invoke/return • Cache contains several methods • Simpler to analyze • At call tree level • Other instructions are a hit Martin Schoeberl – WCET Analysis for a Java Processor
Method Cache Analysis • Only call tree leaves • Return is always a hit • Invoke in a loop for (int i=0; i<10; ++i) { foo(); } • One miss and 9 hits • Miss times added to the CFG Martin Schoeberl – WCET Analysis for a Java Processor
Miss Times in the CFG => Martin Schoeberl – WCET Analysis for a Java Processor
Evaluation Martin Schoeberl – WCET Analysis for a Java Processor
Conclusion • We need static WCET analysis • COTS processors don’t work • Design HW for WCET • A RT computer architecture • JOP is a first step to RT processors • Analysis at bytecode level Martin Schoeberl – WCET Analysis for a Java Processor
Future Work • Method cache cont. • Detection of loop bounds • Integration into Eclipse • WC memory consumption Martin Schoeberl – WCET Analysis for a Java Processor
Demo Time Martin Schoeberl – WCET Analysis for a Java Processor
Thank You! Questions & Suggestions Martin Schoeberl – WCET Analysis for a Java Processor