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