How a Java VM can get more from a hardware performance monitor

Inoue, Hiroshi; Nakatani, Toshio

doi:10.1145/1639949.1640100

Cited by 13 publications

(13 citation statements)

References 33 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…For example, our HPM-based techniques do not require additional metadata to translate the instruction addresses into Java bytecode while previous techniques require huge amounts of additional metadata for this purpose. We implemented a framework to obtain HPM profiles from the JVM by adapting the earlier work [17] to obtain L1 and L2 data cache miss profiles at runtime. To focus on the mutator performance, we do not include the cache misses during stop-theworld GC in the profiles.…”

Section: Object Placement Optimizations Using Hpmmentioning

confidence: 99%

See 1 more Smart Citation

Identifying the sources of cache misses in Java programs without relying on hardware counters

InoueHiroshi

NakataniToshio

2012

SIGPLAN Not.

Self Cite

View full text Add to dashboard Cite

Cache miss stalls are one of the major sources of performance bottlenecks for multicore processors. A Hardware Performance Monitor (HPM) in the processor is useful for locating the cache misses, but is rarely used in the real world for various reasons. It would be better to find a simple approach to locate the sources of cache misses and apply runtime optimizations without relying on an HPM. This paper shows that pointer dereferencing in hot loops is a major source of cache misses in Java programs. Based on this observation, we devised a new approach to identify the instructions and objects that cause frequent cache misses. Our heuristic technique effectively identifies the majority of the cache misses in typical Java programs by matching the hot loops to simple idiomatic code patterns. On average, our technique selected only 2.8% of the load and store instructions generated by the JIT compiler and these instructions accounted for 47% of the L1D cache misses and 49% of the L2 cache misses caused by the JIT-compiled code. To prove the effectiveness of our technique in compiler optimizations, we prototyped object placement optimizations, which align objects in cache lines or collocate paired objects in the same cache line to reduce cache misses. For comparison, we also implemented the same optimizations based on the accurate information obtained from the HPM. Our results showed that our heuristic approach was as effective as the HPMbased approach and achieved comparable performance improvements in the SPECjbb2005 and SPECpower_ssj2008 benchmark programs.

show abstract

Section: Object Placement Optimizations Using Hpmmentioning

confidence: 99%

“…To avoid excessive allocation-time overhead, we do not use this object collocation and alignment optimization if the object creation frequency of one of the target classes exceeds 10% based on the object creation profile generated using HPM information [17].…”

Section: Object Collocation Optimization Using Hpmmentioning

confidence: 99%

Identifying the sources of cache misses in Java programs without relying on hardware counters

InoueHiroshi

NakataniToshio

2012

SIGPLAN Not.

Self Cite

View full text Add to dashboard Cite

show abstract

“…Inoue and Nakatani [14] describe a Java profiler that uses hardware events to take samples of only the executing method and its stack depth. It builds a CCT through matching stack depths and caller information, and is reported to achieve an overhead of 2.2% at 16000 samples per second.…”

Section: Profilingmentioning

confidence: 99%

Lightweight Java Profiling with Partial Safepoints and Incremental Stack Tracing

Höfer

Gnedt

Mössenböck

2015

Proceedings of the 6th ACM/SPEC International Conference on Performance Engineering

View full text Add to dashboard Cite

Sampling profilers are popular because of their low and adjustable overhead and because they do not distort the profile by modifying the application code. A typical sampling profiler periodically suspends the application threads, walks their stacks, and merges the resulting stack traces into a calling context tree. Java virtual machines offer a convenient interface to accomplish this, but rely on safepoints, a synchronization mechanism that requires all threads to park in a safe location. However, a profiler is primarily interested in the running threads, and waiting for all threads to reach a safe location significantly increases the overhead. In most cases, taking a complete stack trace is also unnecessary because many stack frames remain unchanged between samples.We present three techniques that reduce the overhead of sampling Java applications. Partial safepoints require only a certain number of threads to enter a safepoint and can be used to sample only the running threads. With self-sampling, we parallelize taking stack traces by having each thread take its own stack trace. Finally, incremental stack tracing constructs stack traces lazily and examines each stack frame only once instead of walking the entire stack for each sample. Our techniques require no support from the operating system or hardware. With our implementation in the popular HotSpot virtual machine, we show that we can significantly reduce the overhead of sampling without affecting the accuracy of the profiles.

show abstract

“…Context sensitivity is crucial for understanding the behavior of large object-oriented programs [Inoue and Nakatani 2009;Lhoták and Hendren 2008]. Unlike static analysis, however, prior work on dynamic analysis has largely avoided context sensitivity because no efficient technique was known.…”

Section: Why Context Sensitivity?mentioning

confidence: 99%

Breadcrumbs

2010

View full text Add to dashboard Cite

Calling context-the set of active methods on the stack-is critical for understanding the dynamic behavior of large programs. Dynamic program analysis tools, however, are almost exclusively context insensitive because of the prohibitive cost of representing calling contexts at run time. Deployable dynamic analyses, in particular, have been limited to reporting only static program locations. This paper presents Breadcrumbs, an efficient technique for recording and reporting dynamic calling contexts. It builds on an existing technique for computing a compact (one word) encoding of each calling context that client analyses can use in place of a program location. The key feature of our system is a search algorithm that can reconstruct a calling context from its encoding using only a static call graph and a small amount of dynamic information collected at cold (infrequently executed) callsites. Breadcrumbs requires no offline training or program modifications, and handles all language features, including dynamic class loading.We use Breadcrumbs to add context sensitivity to two dynamic analyses: a data-race detector and an analysis for diagnosing null pointer exceptions. On average, it adds 10% to 20% runtime overhead, depending on a tunable parameter that controls how much dynamic information is collected. Collecting less information lowers the overhead, but can result in a search space explosion. In some cases this causes reconstruction to fail, but in most cases Breadcrumbs produces non-trivial calling contexts that have the potential to significantly improve both the precision of the analyses and the quality of the bug reports.

show abstract

How a Java VM can get more from a hardware performance monitor

Cited by 13 publications

References 33 publications

Identifying the sources of cache misses in Java programs without relying on hardware counters

Identifying the sources of cache misses in Java programs without relying on hardware counters

Lightweight Java Profiling with Partial Safepoints and Incremental Stack Tracing

Breadcrumbs

Contact Info

Product

Resources

About