Embedding GI inside the JVM Benoit Baudry Kwaku Yeboah-Antwi 1 - PowerPoint PPT Presentation

Embedding GI inside the JVM Benoit Baudry Kwaku Yeboah-Antwi 1

Specialize to environment .. or not 2

Open-ended evolution 3

Continuously evolve 4

In software • Code specialization • API are large and generic • exact usage (e.g., surface really needed) is known only at runtime • Spontaneous diversification • Instantiation creates large quantities of clones • diversification at instantiation can increase resilience 5

Let’s do it in Java • JVM hardly supports runtime modifications of the bytecode • E.g., add, delete or rename fields, methods • No built-in support • to edit the bytecode • to steer the search for new code 6

Our Contribution ECSELR • EC ologically Inspired S oftware E vo L ution @ R untime • A patch in the JVM + evolutionnary capacities for Java programs 7

The evo loop Action FN Object A Object B EvoAgent Initialization getAllObjects() Object D Object C Evo Strategy Object C Selection EvoDaemon selectObjects() Object B Genetic Oper Object C ’ Variation EvoDaemon mutateObject() Object B ’ Action FN Object C ’ records of Evaluation EvoAgent Object B ’ testObjects() Fitness EvoDaemon Object B ’ discardUnfit() Action FN Installation EvoAgent redefObjects()

The and steps Initialization Selection • Analyze all live objects on the heap • Select a subset according to some function • random • by size • by frequency of usage • Copy the bytecode of selected objects 10

The step Variation • ECSELR embeds default evo operations • Method Addition • Merge Methods • Method Deletion • Field Addition Operator • Transplantation Operator • Random Instruction Operator • Passthrough Operator Return 11

The step Evaluation • Static check • ensure syntactic validity • check consistency after evolution: ECSLER embeds checks about the well-formedness of bytecode operatinos • Dynamic check • parallel execution of original and evolved • fitness evaluation 12

Static check Bytecode ✔ public int greaterThan(int intOne, intTwo) { 0: iload_1 if (intOne > intTwo) { return 0; 1: iload_2 } else { 2: nop return 1; 3: if_icmple 8 } 6: iconst_0 } 7: ireturn 8: iconst_1 greaterThan(10,20); 9: ireturn 13

Static check Bytecode ✗ public int greaterThan(int intOne, intTwo) { if (intOne > intTwo) { 0: iload_1 return 0; 1: iload_2 } else { 2: if_icmple 7 return 1; 5: iconst_0 } 6: ireturn } 7: iconst_1 greaterThan(10,20); 8: ireturn ECSELR detects the mistake: it knows that if_icmple requires two operands 14

Dynamic checks inputs • Run both versions in parallel original mutated • for a given period • This requires our patched JVM out_o out_m eval fitness if ok if not ok keep mutated discard mutated 15

Diversification example int hash( final Object key) { int h = key.hashCode(); h += ~(h << 9); h ^= h >>> 14; h += h << 4; h ^= h >>> 10; return h; } 16

17

Diversification example public long hash() { long h = this .hashCode(); h = this .initCapacity * h; h += ~(h << 9); h ^= h >>> 14; h += h << 4; h ^= h >>> 10; return h; } public long hash() { public long hash() { public long hash() { long h = this .hashCode(); long h = this .hashCode(); long h = this .hashCode(); h = this .initCapacity * h; h = this .initCapacity * h; h = this .initCapacity * h; h += ~(h << 9); h += ~(h << 9); h += ~(h << 9); h ^= h >>> 14; h ^= h >>> 14; h ^= h >>> 14; h += h << 4; h += h << (4+6); h ^= h >>> 10; h += h << (4+6); return h + h; h ^= h >>> 10; h ^= h >>> 10; } h = h * 100; return h; } return h; } 18

Conclusion • We now have a machine to evolve Java programs at runtime • Next step: use it for runtime GI • https://bitbucket.org/Kwaku/agentd/src 19