Inside Out: A Modern Virtual Machine Revealed

Transcription

1 Inside Out: A Modern Virtual Machine Revealed John Coomes Brian Goetz Tony Printezis Sun Microsystems

2 Some Questions > Why not compile my program to an executable ahead of time? > Why can't I tell the VM what/when to compile? > Why not save and reuse the compiled code? > Why not include an explicit free() method? 2

3 Some Questions > Why not compile my program to an executable ahead of time? > Why can't I tell the VM what/when to compile? > Why not save and reuse the compiled code? > Why not include an explicit free() method? > Answers: coming up... 3

4 Virtual Machine > An abstraction layer Between application and system Provides virtual instruction set > Offers Portability write once, run anywhere Security VM is intermediary between application and system resources Performance monitor application behavior Adapt, recompile, etc., as conditions change Productivity enable higher level abstractions 4

5 Virtual Machine > Virtual instruction set (bytecode) May offer higher-level abstractions than native instructions sets May constrain the programming model Usually for good reason! Example: no pointers Enables significant performance optimizations Enables relocating garbage collection > Two opportunities for compilation Static compilation source to bytecode Dynamic compilation bytecode to native 5

6 Dynamic Compilation > Happens while program is running JIT == "just in time" compilation Part of VM, not javac > When a method is first run, bytecode is interpreted VM gathers profiling data If a method is hot enough It is compiled to native code by the JIT compiler Execute native code on next call to method Or transfer to native code while still in the method If necessary... Invalidate native code and recompile 6

7 Dynamic Compilation > Compiler has more information better decisions Precise knowledge of target hardware Number and type of CPUs, cache line size, NUMA, etc. Whole-program information Which classes are loaded right now Online profiling Which branches taken, which not Which loops are hot Whether a null obj has been seen at a given point > Enables adaptive and speculative techniques Compile optimistically, recover if necessary 7

8 Dynamic Compilation > Very flexible! Can freely mix interpretation and native execution > Events can invalidate compiled code New classes being loaded Change in program behavior (phase change) Gathering more profiling data > Must be able to recover Deoptimization interpret and/or recompile > Benefit: better long-term performance > Cost: less predictable short-term performance 8

9 VM Philosophy > Make the common case fast Don't worry about uncommon/infrequent case > Defer optimization decisions Until you have enough data Revisit prior decisions if new data warrants > Cede some control, and you will be rewarded No pointers safety, fast allocation, efficient GC, many optimizations Dynamic compilation better data, speculative optimizations 9

10 Virtual Method Calls > Virtual method calls can be more expensive than direct calls > C++ approach: Make programmer decide virtual vs. non-virtual Don't make me pay for what I don't use > VM approach: Make them fast when necessary (and possible) Let the VM agonize over low-level performance details 10

11 Virtual Method Calls > Overhead: 2 or 3 dependent loads + branch C++ is similar 11

12 Virtual Method Calls > VM has multiple tricks to speed up method dispatch Devirtualize avoid redundant branch target computation Some methods are obviously monomorphic static, final, and private methods Much more pipeline-friendly! Inlining eliminate call overhead entirely Copy the callee code right into the calling method Inline decision based on time/space tradeoff heuristics Inline caching cache target in generated code Fast receiver-type check plus predictable branch 12

13 Inlining > Not just about eliminating call overhead Provides optimizer with bigger blocks Enables other optimizations Hoisting, dead code elimination, common subexpression elimination, code motion, strength reduction, > When inlined, invocation overhead is zero > Most small methods are inlined Such as getters and setters Inlined code is more compact than a call Moral: don't fret about small methods 13

14 Inlining > What kinds of method calls can we inline? Nearly everything! static Always final Always private Always virtual Often reflective Sometimes 14

15 Example 1 class BailoutFund { private int _spent; // in billions void bailout(string name, int amount) { DB.log(name); _spent += amount; 15

16 Example 1 BailoutFund fund = new BailoutFund(...); fund.bailout("john's Insurance", 24); class BailoutFund { private int _spent; // in billions void bailout(string name, int amount) { DB.log(name); _spent += amount; Initial (Naïve Version) if (fund == null) throw new NullPointerException(); fund.bailout("john's Insurance", 24); Virtual call 16

17 Example 1 > fund was just allocated and allocation was successful > JIT can prove fund is not null Can safely eliminate the null check Step 1: Null Check Elimination if (fund == null) throw new NullPointerException(); fund.bailout("john's Insurance", 24); 17

18 Example 1 BailoutFund fund = new BailoutFund(...); fund.bailout("john's Insurance", 24); class BailoutFund { private int _spent; // in billions void bailout(string name, int amount) { DB.log(name); _spent += amount; Intermediate fund.bailout("john's Insurance", 24); Virtual call 18

19 Example 1 > VM knows that bailout() is not overriden Class hierarchy analysis > Can inline bailout() Avoids the virtual call Step 2: Inline bailout() fund.bailout("john's Insurance", 24); DB.log("John's Insurance"); fund._spent += 24; 19

20 Example 1 BailoutFund fund = new BailoutFund(...); fund.bailout("john's Insurance", 24); class BailoutFund { private int _spent; // in billions void bailout(string name, int amount) { DB.log(name); _spent += amount; Final (Optimized Version) DB.log("John's Insurance"); fund._spent += 24; 20

21 Speculative Optimization > If a method is truly monomorphic, we can inline it But how can we know? Classes are loaded dynamically No such thing as a "fully linked executable" Closed-world whole-program analysis is impossible Or is it? > VM can analyze the classes currently loaded And optimize based on that May have to back out optimizations If a subsequent class load would violate assumptions Then recompile the affected code 21

22 Standard Compiler Optimizations > Dynamic compilers can apply all the standard optimizations Dead code elimination Loop-invariant code hoisting Common subexpression elimination Loop unrolling and strength reduction Null check and array bounds check elimination > Inlining more opportunities for these optimizations 22

23 Example 2 class BailoutItem { final private String _name; final private int _amount; // in billions BailoutItem(String name, int amount) { _name = name; _amount = amount; String name() { return _name; int amount() { return _amount; 23

24 Example 2 BailoutFund fund = new BailoutFund(...); BailoutItem[] items = new BailoutItem[...]; // fill in items[]... for (int i = 0; i < items.length; ++i) fund.bailout(items[i].name(), items[i].amount()); class BailoutItem { final private String _name; final private int _amount; // in billions BailoutItem(String name, int amount) { _name = name; _amount = amount; String name() { return _name; int amount() { return _amount; Initial (Naïve Version) for (int i = 0; i < items.length; ++i) { if (i < 0 items.length <= i) throw new ArrayIndexOOBE(); fund.bailout(items[i].name(), items[i].amount()); 24

25 Example 2 > Array bounds checks required by the language Potentially expensive > Can prove i is in range Eliminate array bounds check safely Step 1: Bounds Check Elimination for (int i = 0; i < items.length; ++i) { if (i < 0 items.length <= i) throw new ArrayIndexOOBE(); fund.bailout(items[i].name(), items[i].amount()); 25

26 Example 2 BailoutFund fund = new BailoutFund(...); BailoutItem[] items = new BailoutItem[...]; // fill in items[]... for (int i = 0; i < items.length; ++i) fund.bailout(items[i].name(), items[i].amount()); class BailoutItem { final private String _name; final private int _amount; // in billions BailoutItem(String name, int amount) { _name = name; _amount = amount; String name() { return _name; int amount() { return _amount; Intermediate for (int i = 0; i < items.length; ++i) { fund.bailout(items[i].name(), items[i].amount()); 26

27 Example 2 > Hoist invariant code Likely into a register No need to access items.length every time around the loop Step 2: Hoist items.length int length = items.length; for (int i = 0; i < items.length; ++i) { fund.bailout(items[i].name(), items[i].amount()); length 27

28 Example 2 BailoutFund fund = new BailoutFund(...); BailoutItem[] items = new BailoutItem[...]; // fill in items[]... for (int i = 0; i < items.length; ++i) fund.bailout(items[i].name(), items[i].amount()); class BailoutItem { final private String _name; final private int _amount; // in billions BailoutItem(String name, int amount) { _name = name; _amount = amount; String name() { return _name; int amount() { return _amount; Intermediate int length = items.length; for (int i = 0; i < length; ++i) { fund.bailout(items[i].name(), items[i].amount()); 28

29 Example 2 > Avoid redundant memory accesses Read items[i] once in the loop, not twice Likely kept in a register Step 3: Sub-Expression Elimination int length = items.length; for (int i = 0; i < length; ++i) { BailoutItem item = items[i]; fund.bailout(items[i].name(), items[i].amount()); item 29

30 Example 2 BailoutFund fund = new BailoutFund(...); BailoutItem[] items = new BailoutItem[...]; // fill in items[]... for (int i = 0; i < items.length; ++i) fund.bailout(items[i].name(), items[i].amount()); class BailoutItem { final private String _name; final private int _amount; // in billions BailoutItem(String name, int amount) { _name = name; _amount = amount; String name() { return _name; int amount() { return _amount; Intermediate int length = items.length; for (int i = 0; i < length; ++i) { BailoutItem item = items[i]; fund.bailout(item.name(), item.amount()); 30

31 Example 2 > VM knows name() and amount() are not overridden Class hierarchy analysis > Can inline name() and amount() Avoids virtual calls > Must record dependencies Single implementer of name() and amount() Allows recovery Step 4: Inline name() and amount() int length = items.length; for (int i = 0; i < length; ++i) { BailoutItem item = items[i]; fund.bailout(item.name(), item.amount()); (item._name, item._amount) 31

32 Example 2 BailoutFund fund = new BailoutFund(...); BailoutItem[] items = new BailoutItem[...]; // fill in items[]... for (int i = 0; i < items.length; ++i) fund.bailout(items[i].name(), items[i].amount()); class BailoutItem { final private String _name; final private int _amount; // in billions BailoutItem(String name, int amount) { _name = name; _amount = amount; String name() { return _name; int amount() { return _amount; Intermediate int length = items.length; for (int i = 0; i < length; ++i) { BailoutItem item = items[i]; fund.bailout(item._name, item._amount); 32

33 Example 2 > VM knows that bailout() is not overriden Class hierarchy analysis > Can inline bailout() Avoids the virtual call > Must record dependency Single implementer of bailout() Allows recovery Step 4: Inline bailout() int length = items.length; for (int i = 0; i < length; ++i) { BailoutItem item = items[i]; fund.bailout(item._name, item._amount); DB.log(item._name); fund._spent += item._amount; 33

34 Example 2 BailoutFund fund = new BailoutFund(...); BailoutItem[] items = new BailoutItem[...]; // fill in items[]... for (int i = 0; i < items.length; ++i) fund.bailout(items[i].name(), items[i].amount()); class BailoutItem { final private String _name; final private int _amount; // in billions BailoutItem(String name, int amount) { _name = name; _amount = amount; String name() { return _name; int amount() { return _amount; Final (Optimized Version) int length = items.length; for (int i = 0; i < length; ++i) { BailoutItem item = items[i]; DB.log(item._name); fund._spent += item._amount; 34

35 Scalar Replacement > Object allocation (new) is under programmer control Mostly the VM can fake us out User deals in references, but VM owns the pointers VM can often optimize away allocations Even though allocation is fast, extra objects still cause GC churn and more cache misses > Many objects are just holders for related values Like java.awt.point VM can put fields in registers - object is unnecessary This is called scalar replacement 35

36 Escape Analysis > Eliding allocation relies on escape analysis Tells us if a reference escapes a certain scope Such as the method in which it was allocated Determines dynamic scope of object reference > If an object does not escape Can eliminate heap allocation Place fields into registers or allocate on stack Can eliminate locking > Inlining more opportunities for escape analysis 36

37 Example 3 class Treasury {... BailoutItem nextbailout() { return new BailoutItem(nextName(), calcamount()); 37

38 Example 3 Treasury treasury = new Treasury(...); BailoutFund fund = new BailoutFund(...); BailoutItem item = treasury.nextbailout(); fund.bailout(item.name(), item.amount()); Initial (Naïve Version) BailoutItem item = treasury.nextbailout(); fund.bailout(item.name(),item.amount()); class Treasury {... BailoutItem nextbailout() { return new BailoutItem(nextName(), calcamount()); 38

39 Example 3 > VM knows that nextbailout() is not overriden Class hierarchy analysis > Can inline nextbailout() Avoids the virtual call > Must record dependency Single implementer of nextbailout() Step 1: Inline nextbailout() BailoutItem item = treasury.nextbailout(); fund.bailout(item.name(), item.amount()); new BailoutItem(treasury.nextName(), treasury.calcamount()); 39

40 Example 3 Treasury treasury = new Treasury(...); BailoutFund fund = new BailoutFund(...); BailoutItem item = treasury.nextbailout(); fund.bailout(item.name(), item.amount()); class Treasury {... BailoutItem nextbailout() { return new BailoutItem(nextName(), calcamount()); Intermediate BailoutItem item = new BailoutItem(treasury.nextName(), treasury.calcamount()); fund.bailout(item.name(), item.amount()); 40

41 Example 3 > Assume item is not used further JIT can prove item is nonescaping > Eliminate the allocation of item > Fields become a set of simple (scalar) variables Object item is replaced by variables localname and localamount Likely will only appear in registers Step 2: Scalar Replace Allocation localname = treasury.nextname(); localamount = treasury.calcamount(); BailoutItem item = new BailoutItem(treasury.nextName(), treasury.calcamount()); fund.bailout(item.name(), item.amount()); (localname, localamount) 41

42 Example 3 Treasury treasury = new Treasury(...); BailoutFund fund = new BailoutFund(...); BailoutItem item = treasury.nextbailout(); fund.bailout(item.name(), item.amount()); class Treasury {... BailoutItem nextbailout() { return new BailoutItem(nextName(), calcamount()); Intermediate localname = treasury.nextname(); localamount = treasury.calcamount(); fund.bailout(localname, localamount); 42

43 Example 3 > Remove localname and localamount > They are aliases of treasury.calcamount() and treasury.nextname() Step 3: Eliminate Aliases localname = treasury.nextname(); localamount = treasury.calcamount(); fund.bailout(localname, localamount); (treasury.nextname(), treasury.calcamount()) 43

44 Example 3 Treasury treasury = new Treasury(...); BailoutFund fund = new BailoutFund(...); BailoutItem item = treasury.nextbailout(); fund.bailout(item.name(), item.amount()); Intermediate fund.bailout(treasury.nextname(), treasury.calcamount()); class Treasury {... BailoutItem nextbailout() { return new BailoutItem(nextName(), calcamount()); 44

45 Example 3 > VM knows that bailout() is not overriden Class hierarchy analysis > Can inline bailout() Avoids the virtual call > Must record dependency Single implementer of bailout() Step : Inline bailout() fund.bailout(treasury.nextname(), treasury.calcamount()); DB.log(treasury.nextName()); fund._spent += treasury.calcamount(); 45

46 Example 3 Treasury treasury = new Treasury(...); BailoutFund fund = new BailoutFund(...); BailoutItem item = treasury.nextbailout(); fund.bailout(item.name(), item.amount()); Final (Optimized Version) DB.log(treasury.nextName()); fund._spent += treasury.calcamount(); class Treasury {... BailoutItem nextbailout() { return new BailoutItem(nextName(), calcamount()); 46

47 Lock Coarsening > Reduces the overhead of locking > Combine adjacent synchronized blocks That lock the same object > Can also move code into (but not out of) a synchronized block to facilitate lock coarsening 47

48 Example 4 class BailoutFund {... synchronized void bailoutmt(string name, long amount) { bailout(name, amount); 48

49 Example 4 BailoutFund fund = new BailoutFund(...); fund.bailoutmt("john's Insurance", 24); fund.bailoutmt("brian's Bank", 10); fund.bailoutmt("tony's Car Factory", 16); class BailoutFund {... synchronized void bailoutmt(string name, long amount) { bailout(name, amount); Initial (Naïve Version) lock(fund); fund.bailoutmt("john's Insurance", 24); unlock(fund); lock(fund); fund.bailoutmt("brian's Bank", 10); unlock(fund); lock(fund); fund.bailoutmt("tony's Car Factory", 16); unlock(fund); 49

50 Example 4 > Three adjacent blocks All lock the same object Assume blocks are small enough > Interior lock / unlock operations can be removed Step 1: Lock Coarsening lock(fund); fund.bailoutmt("john's Insurance", 24); unlock(fund); lock(fund); fund.bailoutmt("brian's Bank", 10); unlock(fund); lock(fund); fund.bailoutmt("tony's Car Factory", 16); unlock(fund); 50

51 Example 4 BailoutFund fund = new BailoutFund(...); fund.bailoutmt("john's Insurance", 24); fund.bailoutmt("brian's Bank", 10); fund.bailoutmt("tony's Car Factory", 16); class BailoutFund {... synchronized void bailoutmt(string name, long amount) { bailout(name, amount); Intermediate lock(fund); fund.bailoutmt("john's Insurance", 24); fund.bailoutmt("brian's Bank", 10); fund.bailoutmt("tony's Car Factory", 16); unlock(fund); 51

52 Example 4 > VM knows that bailoutmt() and bailout() are not overriden Class hierarchy analysis > Can inline bailoutmt() and bailout() Avoids the virtual calls > Must record dependencies Single implementer of bailout() and bailoutmt() Step 2: Inline bailoutmt lock(fund); fund.bailoutmt("john's Insurance", 24); fund.bailoutmt("brian's Bank", 10); fund.bailoutmt("tony's Car Factory", 16); unlock(fund); DB.log( John's Insurance ); fund._spent += 24; DB.log( Brian's Bank ); fund._spent += 10; DB.log( Tony's Car Factory ); fund._spent += 16; 52

53 Example 4 BailoutFund fund = new BailoutFund(...); fund.bailoutmt("john's Insurance", 24); fund.bailoutmt("brian's Bank", 10); fund.bailoutmt("tony's Car Factory", 16); class BailoutFund {... synchronized void bailoutmt(string name, long amount) { bailout(name, amount); Final (Optimized Version) lock(fund); DB.log( John's Insurance ); fund._spent += 24; DB.log( Brian's Bank ); fund._spent += 10; DB.log( Tony's Car Factory ); fund._spent += 16; unlock(fund); 53

54 Lock Elision > Further reduces the overhead of locking > If the JIT can prove that an object is non-escaping It is guaranteed that only one thread will access it Therefore, no synchronization is necessary Can totally elide synchronization for that object 54

55 Example 4 (Alt 1) BailoutFund fund = new BailoutFund(...); fund.bailoutmt("john's Insurance", 24); fund.bailoutmt("brian's Bank", 10); fund.bailoutmt("tony's Car Factory", 16); class BailoutFund {... synchronized void bailoutmt(string name, long amount) { bailout(name, amount); Final (with Lock Elision) lock(fund); DB.log( John's Insurance ); fund._spent += 24; DB.log( Brian's Bank ); fund._spent += 10; DB.log( Tony's Car Factory ); fund._spent += 16; unlock(fund); 55

56 Biased Locking > Even if we cannot coarsen / elide synchronization, we can still optimize it > Often, object A is only ever locked by thread T The VM can bias object A to thread T T never needs to lock A again A simple test proves that A is biased to T > If, however, another thread tries to lock A The VM will need to unbias A This is very expensive 56

57 Example 4 (Alt 2) BailoutFund fund = new BailoutFund(...); fund.bailoutmt("john's Insurance", 24); fund.bailoutmt("brian's Bank", 10); fund.bailoutmt("tony's Car Factory", 16); class BailoutFund {... synchronized void bailoutmt(string name, long amount) { bailout(name, amount); Final (with Biased Locking) if (fund.biased_to()!= Thread.current()) { // fund biased/locked by another thread: // revoke bias, then acquire lock DB.log( John's Insurance ); fund._spent += 24; DB.log( Brian's Bank ); fund._spent += 10; DB.log( Tony's Car Factory ); fund._spent += 16; 57

58 Inline caching > Pure inlining is great, but not always possible A call site may have multiple targets ( megamorphic ) But the most likely one may still be known Thanks to online profiling And we can optimize for the common case! > If a single target is very common, it can generate an "inline cache" Cache predicted jump target in code Do a fast type check, and if receiver type matches predicted, branch to predicted target Hardware can predict this branch effectively 58

59 Example 5 class BailoutFund { private int _spent; // in billions void bailout(string name, int amount) { DB.log(name); _spent += amount; class TARPFund extends BailoutFund { void bailout(string name, int amount) {... 59

60 Example 5 BailoutFund fund = new BailoutFund(...); fund.bailout("john's Insurance", 24); class BailoutFund { private int _spent; // in billions void bailout(string name, int amount) { DB.log(name); _spent += amount; class TARPFund extends BailoutFund { void bailout(string name, int amount) {... Initial (Naïve Version) fund.bailout("john's Insurance", 24); Virtual call 60

61 Example 5 > JIT cannot inline bailout() unconditionally It is overriden > However, assume that in most cases fund is an instance of BailoutFund Dynamic profiling tells us > Add a fast type check and inline the common case Avoids the virtual call for the common case Step 2: Inline bailout() and type check fund.bailout("john's Insurance", 24); if (fund.getclass() == BailoutFund) { DB.log("John's Insurance"); fund._spent += 24; else { fund.bailout("john's Insurance", 24); 61

62 Example 5 BailoutFund fund = new BailoutFund(...); fund.bailout("john's Insurance", 24); class BailoutFund { private int _spent; // in billions void bailout(string name, int amount) { DB.log(name); _spent += amount; class TARPFund extends BailoutFund { void bailout(string name, int amount) {... Final (Optimized Version) if (fund.getclass() == BailoutFund) { DB.log("John's Insurance"); fund._spent += 24; else { fund.bailout("john's Insurance", 24); Virtual call 62

63 Garbage Collection > Automatic memory management As opposed to explicit malloc / free > The usual advantages Eliminates dangling pointers Eliminates memory leaks But not memory retention Improves productivity Simpler API/library design > Trade-offs Less predictability Throughput? 63

64 Object Relocation > Garbage collection enables object relocation Compaction: eliminates fragmentation Generational GC: decreases GC overhead Linear Allocation: best allocation performance Fast path: ~10 instructions, inlined, no synchronization top new top end new object 64

65 Garbage Collection and Throughput > Recent publication shows malloc / free outperform GC when heap is tight But: GC can match (or better) malloc / free when there is enough breathing room Matthew Hertz and Emery Berger, Quantifying the performance of garbage collection vs. explicit memory management. In Proceedings of OOPSLA '05, Oct

66 Generational GC Is Fast! > malloc / free cost malloc * all_objects + cost free * freed_objects > Generational GC with Copying Young Generation cost linear_alloc * all_objects + cost copy * surviving_objects Notice: no reclamation cost (i.e, cost free ) for all reclaimed objects in the young generation > But consider cost linear_alloc much lower than cost malloc surviving_objects say ~5% or less of all_objects 66

67 Object Relocation Other Benefits > Compaction: can improve page locality > Relocation order: can improve cache locality > Important points Object allocation & reclamation are fast Object relocation can also improve application performance 67

68 Obscure Optimizations > Significant payoff On some hardware For some applications > But tedious to do in portable C/C++ apps > VM gives them for free Large Pages NUMA 68

69 Large Pages > Scarce resources: Disk? 69

70 Large Pages > Scarce resources: Disk? 1 TB for under $100! RAM? 70

71 Large Pages > Scarce resources: Disk? 1 TB for under $100! RAM? Laptops have 2+ GB Cache? 71

72 Large Pages > Scarce resources: Disk? 1 TB for under $100! RAM? Laptops have 2+ GB Cache? Maybe, but not what I'm looking for... TLB Cache of virtual physical address mappings Used on many (or all) memory references TLB miss memory access even slower Must walk page tables 72

73 Large Pages > TLBs are scarce A few 10s to a few 100s of entries With 4 KB pages Need 1M entries to cover 4 GB > What to do? Make TLB larger add more entries Must remain very fast Hard to keep up with memory growth Allow TLB entries to cover a larger region Large pages 64 KB, 2 MB, 4 MB, 256 MB, 1 GB 73

74 Large Pages > Exploiting large pages VM queries OS for available page sizes Selects appropriate size for Java heap Young + old generations Permanent generation Dynamically generated code Other structures Card table, bitmaps, region tables > Performance boost: 5% - 10% With large heaps, on some benchmarks; YMMV 74

75 Large Pages > OS Support Solaris Enabled by default More than two page sizes Regions can expand and contract Linux, Windows Administrator must enable Search web for java large pages At most two page sizes Region size fixed at initialization > Summary: obscure, but worth it 75

76 NUMA > All memory is not equal > Each CPU can access Local memory Remote memory Longer latency up to 2x > Hypothetical: 4 locality groups Random placement wrong 75% of the time CPU starved for data > Solution? 76

77 NUMA > Make VM NUMA-aware Each thread has a home node Object allocation Uses memory local to thread's home node when possible 77

78 NUMA > Make VM NUMA-aware Each thread has a home node Object allocation Uses memory local to thread's home node when possible > Payoff: Modest to Huge Some applications, some platforms 2 sockets * 2 cores - 10% 8 sockets * 2 cores - 30% 72 sockets * 2 cores - 280% > Summary: obscure, but necessary 78

79 Conclusions > Give up some control Pointers Ahead-of-time compilation Some predictability > Get a lot back Performance Ultra-fast allocation Dynamic optimizations Safety No pointer bugs Portability 79

80 Acknowledgements > Vladimir Kozlov > Igor Veresov > John Rose > Charlie Hunt 80

81 John Coomes Brian Goetz Tony Printezis