Altering Java Semantics via Bytecode Manipulation Eric Tanter, - - PowerPoint PPT Presentation

Jinline

Altering Java Semantics via Bytecode Manipulation

´ Eric Tanter, Marc S´ egura-Devillechaise, Jacques Noy´ e, Jos´ e Piquer

{etanter, jpiquer}@dcc.uchile.cl {msegura, jnoye}@emn.fr.

DCC–University of Chile (Chile), OBASCO–Ecole des Mines de Nantes (France)

• E. Tanter et al. – Altering Java Semantics via Bytecode Manipulation – ACM GPCE 2002, Pittsburgh, MA, 6-8 October – p.1/17

Contents

• An Example
• Introduction
• Jinline

Approach

Overview

Process

Guarantees

• Current state, perspectives & conclusion
• E. Tanter et al. – Altering Java Semantics via Bytecode Manipulation – ACM GPCE 2002, Pittsburgh, MA, 6-8 October – p.2/17

An Example Set up a Factory pattern [GoF]:

• server handling requests with concurrent workers of

different types

available implementation starts a new thread for each request

want to have a factory managing an instance pool

replace new WorkerXXX(arg1, arg2, ...);

with a generic code: Factory.getInstance("WorkerA", [..args..]);

• E. Tanter et al. – Altering Java Semantics via Bytecode Manipulation – ACM GPCE 2002, Pittsburgh, MA, 6-8 October – p.3/17

Introduction (1) Altering semantics of Java programs

• Areas of application:

Application customization

OTS Component integration

Separation of concerns (reflection, AOP)

• Need for performing alterations on binaries (Java

bytecode)

binary components

• pen distributed systems with dynamic class loading
• E. Tanter et al. – Altering Java Semantics via Bytecode Manipulation – ACM GPCE 2002, Pittsburgh, MA, 6-8 October – p.4/17

Introduction (2) Granularity of alterations

• Coarse-grained: outside methods

class hierarchies, interfaces, class members, ...

e.g. structural reflection with Javassist [Chiba], BCA [Keller]

• Fine-grained: within method bodies

sometimes necessary (e.g., previous example)

as of now, either low level, unsafe

• general-purpose bytecode manipulation (BCEL [Dahm], JOIE [Cohen]...)
• bytecode = language semantics + stack code

• r limited (not generic)
• Javassist’ code converter
• new WorkerA(a1, a2); → Factory.getWorkerA(a1, a2);
• E. Tanter et al. – Altering Java Semantics via Bytecode Manipulation – ACM GPCE 2002, Pittsburgh, MA, 6-8 October – p.5/17

J i n l i n e

• E. Tanter et al. – Altering Java Semantics via Bytecode Manipulation – ACM GPCE 2002, Pittsburgh, MA, 6-8 October – p.6/17

Approach

• fine-grained alterations on bytecode

load-time transformation by a metaprogram

plugged into the Javassist framework

• source-level abstractions

ease of use

ensure consistency (no direct, error-prone, stack manipulation)

• high expressiveness

approach can be used to transform almost any source language mechanism

• genericity

reify language mechanism occurrences at run-time if needed

• E. Tanter et al. – Altering Java Semantics via Bytecode Manipulation – ACM GPCE 2002, Pittsburgh, MA, 6-8 October – p.7/17

Overview

• transformation of/around language mechanisms
• ccurrences
• inserting code

before/after and instead of

conceptually, insert a call to a method

concretely, inline that method

• E. Tanter et al. – Altering Java Semantics via Bytecode Manipulation – ACM GPCE 2002, Pittsburgh, MA, 6-8 October – p.8/17

Transformation

body to inline prologue bytecode sequence after inlining epilogue

• riginal bytecode

sequence i adjusted body i+1 i+1 i−1 i−1

• E. Tanter et al. – Altering Java Semantics via Bytecode Manipulation – ACM GPCE 2002, Pittsburgh, MA, 6-8 October – p.9/17

Overview (2)

• abstraction level: source code

specify target of transformation at source level: description classes

specify inserted code as source code: standard methods

• E. Tanter et al. – Altering Java Semantics via Bytecode Manipulation – ACM GPCE 2002, Pittsburgh, MA, 6-8 October – p.10/17

Descriptions

• Language mechanisms are represented as description

classes

MessageSend.class

Instantiation.class

• An occurrence of a language mechanism is an

instance of a description class

aMessageSend.getReceiverType()

anInstantiation.getArgumentsTypes()

• E. Tanter et al. – Altering Java Semantics via Bytecode Manipulation – ACM GPCE 2002, Pittsburgh, MA, 6-8 October – p.11/17

Inlined code

• The inlined code is a standard, compiled method

Restriction on the arguments:

• either object array (all dynamic info) or no-arg (more efficient)
• Object newMethod(Object[] jinArgs){

String classname = (String) jinArgs[2]; Object[] args = (Object[]) jinArgs[3]; return Factory.getInstance(classname, args); }

• newMethod(){ System.out.println("here"); }
• code can be inlined in constructors, try, catch, finally, ...

solution to the Factory example is given in the paper (< 15 lines)

• E. Tanter et al. – Altering Java Semantics via Bytecode Manipulation – ACM GPCE 2002, Pittsburgh, MA, 6-8 October – p.12/17

Process of the metaprogram

specify mechanisms of interests - filter occurrences - specify method to inline

1 2 3 4

return inlining

• rder (or null)

5

Jinliner

notify(description, context)

jinlerA

notifyUpon(type, jinlerA) process(myMethod)

analyze static data

• E. Tanter et al. – Altering Java Semantics via Bytecode Manipulation – ACM GPCE 2002, Pittsburgh, MA, 6-8 October – p.13/17

Guarantees

• User has no direct access to bytecode

generated code is valid (passes bytecode verification)

• Signature of methods to inline are checked

args: either Object[] or void

• Integration of inserted code

stack state for instruction i + 1 is left intact

return value

• automatic downcast and unwrapping of primitive types
• if mismatch, then runtime ClassCastException

thrown exceptions

• injection within original exception handling code
• if not expected, wrapped into UndeclaredThrowableException
• E. Tanter et al. – Altering Java Semantics via Bytecode Manipulation – ACM GPCE 2002, Pittsburgh, MA, 6-8 October – p.14/17

Perspectives (1)

• Code explosion might become an issue

Jinline overhead is not the problem

size of the inlined code is an issue

detection is straightforward

possibility of resolving this issue by inserting standard method call instead of inlining

• Composition of transformation

3 possibilities:

• ignore Jinline code and inlined code
• ignore Jinline code and transform inlined code
• transform both

solution based on the use of method attributes

• E. Tanter et al. – Altering Java Semantics via Bytecode Manipulation – ACM GPCE 2002, Pittsburgh, MA, 6-8 October – p.15/17

Perspectives (2)

• Support for more mechanisms

as of now: message/constructor send, instantiation and cast

soon: field/array accesses, RTTI

later: method enter/exit, try/catch/finally enter, ...

• Support for before/after

as of now only instead of

before/after is easier

• Applications

Reification components for Reflex, an open runtime MOP [Tanter]

• provide caller-side metacontrol

Implementation alternative for EAOP [Douence]

• E. Tanter et al. – Altering Java Semantics via Bytecode Manipulation – ACM GPCE 2002, Pittsburgh, MA, 6-8 October – p.16/17

Conclusion

• fine-grained alterations
• no need for source code (bytecode / load time)
• source-level asbtractions
• complements Javassist
• prototype ready, but packaging is not

contact etanter@dcc.uchile.cl or msegura@emn.fr

• E. Tanter et al. – Altering Java Semantics via Bytecode Manipulation – ACM GPCE 2002, Pittsburgh, MA, 6-8 October – p.17/17