View
220
Download
0
Category
Preview:
Citation preview
Profiling Field Initialisation in Java
Stephen Nelson, David J. Pearce &James Noble
Victoria University of WellingtonNew Zealand
Motivation
• “Favour Immutability”, #13, Effective Java:
– "Classes should be immutable unless there's a very good reason to make them mutable....If a class cannot be made immutable, limit its mutability as much as possible.”
– “Immutable classes are easier to design, implement, and use than mutable classes”
-- Josh Bloch
Motivation
• “Favour Immutability”, #13, Effective Java:
– "Classes should be immutable unless there's a very good reason to make them mutable....If a class cannot be made immutable, limit its mutability as much as possible.”
– “Immutable classes are easier to design, implement, and use than mutable classes”
-- Josh Bloch
Q) How well does Java support this?
Field Initialisation
• Java provides final fields to prohibit modification and show intent
• Unfortunately, in this example, cannot declare parent field final
abstract class Parent { private final Child child; public Parent(Child c) { this.child = c; }
}
abstract class Child { private Parent parent;
public void set(Parent p) { parent = p; }
}
Stationary Fields
• A field is stationary if, for all objects, every write occurs before first read
• Unkel & Lam (POPL’08) statically inferred stationary fields – Across corpus of 26 Java Applications, found
between 40-60% of fields were stationary
W RW R
W R W R
More on Stationary Fields
• Final fields are subset of stationary fields:
• Distinguish Declared Final and Undeclared Final
W RW RCE
W RW RCE
W RR RCE
Rprof – Overview
• Our Runtime Profiling Tool:– Whole-program, including standard libraries– No sampling, record and analyse every event– Tracks constructor entry/exit and field read/write
Rprof – Map/Reduce
• Problem: how to handle billions of events?
• Answer: throw more hardware at it!– Event processing done using Map/Reduce – Events processed in parallel to give more
manageable results– Worker threads spread over multiple machines
• Consequence: less flexibility– Must customise map/reduce procedure for each
distinct analysis
Rprof – Map/Reduce Example
1. W #1.f
2. W #2.g
3. W #1.f
4. R #2.g
5. W #2.g
6. R #1.f
1. W #1.f
2. W #2.g
3. W #1.f
4. R #2.g
5. W #2.g
6. R #1.f
1. W #1.f
2. W #2.g
3. W #1.f
4. R #2.g
5. W #2.g
6. R #1.f
Reduce
Reduce
LW: 3FR: 6
LW: 5FR: 4
Experimental Setup
• Methodology:– Profile single run of benchmark with default input– OpenJDK 1.8.0-ea-b37 was the experimental platform (*)– Opteron 254 (2.8GHz) dual CPU with 4GB was
experimental machine
• Dacapo Benchmark Suite– 14 Applications– 701 - 8246 classes– Non-trivial memory loads– Workloads provided– No User Interaction– Reproduceable Results
Results – Overall
Key Observation: 70% -- 80% of fields are stationary
Results – Primitives vs References
Threats to Validity
• Benchmark Inputs– Cannot generalise program behaviour from a single run!– Better to use a set of inputs – but how to generate them?
• Benchmark Scope– Unclear whether DeCapo representative of general
population
• Conclusion:– Our results provide upper bound on number of
stationary fields– Unkel & Lam provide lower bound on number of
stationary fields
Conclusion
• Unkel & Lam – Static inference of stationary fields – Found 40-60% of fields were stationary– Static analysis conservative -> lower bound
• Our results– Complement that of Unkel & Lam– Use runtime profiling instead of static inference– Found 70-80% of fields are stationary– Runtime profiling is unsound -> upper bound
Recommended