logo of the SSW institute ;)
Computer Science
System Software

Home

General
Staff
Contact
Partners
Alumni

Research
Areas
Projects
Papers
Books
Reports
Awards

Teaching
Lectures
Exams
B.Projects
M.Theses
PhD Theses
Go Abroad

Misc
Talks
Library
Gallery
Links
Search

Webmaster


Automatic Feedback-Directed Object Inlining in the Java HotSpot™ Virtual Machine

Christian Wimmer
Institute for System Software
wimmer@ssw.jku.at

Hanspeter Mössenböck
Institute for System Software
Christian Doppler Laboratory for Automated Software Engineering
moessenboeck@ssw.uni-linz.ac.at


Abstract

Object inlining is an optimization that embeds certain referenced objects into their referencing object. It reduces the costs of field accesses by eliminating unnecessary field loads. The order of objects in the heap is changed in such a way that objects that are accessed together are placed next to each other in memory so that their offset is fixed, i.e. the objects are colocated. This allows field loads to be replaced by address arithmetic. We implemented this optimization for Sun Microsystems' Java HotSpot™ VM. The analysis is performed automatically at run time, requires no actions on the part of the programmer and supports dynamic class loading.

We use read barriers to detect the most frequently accessed fields that are worth being optimized. To safely eliminate a field load, the colocation of the object that holds the field and the object that is referenced by the field must be guaranteed. Two preconditions must be satisfied for a field before it is optimized: the objects must be allocated together, and the field must not be overwritten later. These preconditions are checked by the just-in-time compiler to avoid a global data flow analysis. The garbage collector ensures that groups of colocated objects are not split: it copies groups as a whole to their new locations.

The evaluation shows that our dynamic approach successfully identifies and optimizes frequently accessed fields for several benchmarks. The improved peak performance of 9% in average for SPECjvm98 (with a maximum speedup of 51%) justifies the startup overhead of 3% in average (with a maximum slowdown of 11%) that is caused mainly by the read barriers and the additional compilation of methods.


Download as PDF

© ACM, 2007. This is the author's version of the work. It is posted here for your personal use. Not for redistribution.
Published in the Proceedings of the 3rd International Conference on Virtual Execution Environments (VEE'07), pp. 12-21, San Diego, CA, June 2007.
http://doi.acm.org/10.1145/1254810.1254813