asm-transformationse文资源-CSDN文库

需积分: 10 114 浏览量 2011-09-19 11:31:24 上传评论收藏 76KB PDF 举报

asm 常用的操作 The goal of the ASM library is to generate, transform and analyze compiled Java classes, represented as byte arrays (as they are stored on disk and loaded in the Java Virtual Machine). ### 关于ASM库及其在Java字节码转换中的应用 #### 一、引言与背景在当前的软件开发环境中，面向切面编程（AOP）作为一种重要的编程范式，被广泛应用于解决横切关注点问题。对于Java平台而言，由于源代码可能不可用或者难以修改，字节码编织成为实现AOP的一种常见且实用的方法。本文将重点介绍如何利用ASM框架高效地进行Java字节码转换，并探讨其在AOP实现中的应用。 #### 二、ASM框架概述 ASM（Adaptive System of Systems Modeling）是为编译后的Java类生成、转换和分析而设计的一个高性能库。它主要通过操作编译后的字节码（即存储在磁盘上的字节数组以及加载到Java虚拟机中的形式）来实现这一目标。相比其他类似的框架如BCEL、Serp和JOIE等，ASM在性能和内存消耗方面具有显著优势。 #### 三、ASM的设计原则 1. **非对象表示**: 不采用传统的对象表示法来表示字节码，而是通过有限的几类对象来表达复杂的转换逻辑，这使得ASM比Serp和BCEL等框架更加高效。 2. **访问者模式的应用**: 使用访问者模式来避免创建大量对象，从而减少了内存消耗和提高了处理速度。 3. **高效的内存管理**: 通过对数据结构的优化和精简，使得ASM在处理字节码时能够保持快速并且占用极少的内存资源。 #### 四、负载时间字节码编织（Load-Time Bytecode Weaving, LTW）负载时间字节码编织是一种在应用程序代码被加载到Java虚拟机之前进行的字节码转换技术。这种方式简化了开发环境，但同时也对转换工具的性能和内存需求提出了更高要求。为了满足这些需求，ASM框架提供了一系列高效的技术手段。 #### 五、AOP实现中的字节码转换模式 1. **通用型AOP框架的字节码转换**: 在面向切面编程框架中，通常会遇到一系列常见的字节码转换模式。例如，添加日志记录、安全验证等功能，这些功能可以通过特定的字节码转换模式来实现。 2. **复杂转换模式的组合**: 通过将简单的字节码转换模式组合起来，可以构建出更为复杂的转换逻辑，以满足不同场景下的需求。 3. **性能考量**: 在设计和实施字节码转换时，需要特别注意性能的影响。由于字节码转换发生在运行时，因此需要确保转换过程不会对应用程序的整体性能造成显著影响。 #### 六、ASM在实践中的优势 - **性能**: 相较于其他字节码操作框架，ASM在处理大规模字节码时表现出了更好的性能。 - **内存消耗**: 由于采用了非对象表示和访问者模式，ASM在处理字节码时占用的内存资源较少。 - **灵活性**: 通过灵活的API设计，ASM支持多种类型的字节码转换，包括但不限于增加方法、删除方法、修改方法体等。 - **易用性**: 尽管ASM的功能强大，但其API设计直观且易于理解，降低了开发者的使用门槛。 #### 七、总结本文介绍了ASM框架在Java字节码转换方面的应用，并着重讨论了该框架在实现AOP过程中的一些关键技术点。通过对比其他框架，我们可以看出ASM在性能、内存消耗等方面的优势。此外，ASM还提供了丰富的API接口，使得开发者能够方便地进行各种字节码级别的操作，从而更好地支持面向切面编程的实现。随着AOP技术在实际项目中的广泛应用，ASM作为字节码操作领域的重要工具之一，其价值也将得到进一步体现。

资源推荐

资源详情

资源评论

Using the ASM framework to implement common Java

bytecode transformation patterns

Eugene Kuleshov, eu@javatx.org

ABSTRACT

Most AOP frameworks targeting the Java platform use a bytecode

weaving approach as it is currently considered the most practical

solution. It allows applying cross-cutting concerns to Java

applications when source code is not available, is portable and

works on existing JVMs, in comparison to VM-level AOP

implementations.

Load-time bytecode weaving (LTW), which happens right before

the application code is loaded into the Java VM, significantly

simplifies development environment, but also raises the bar for

the performance and memory requirements for these

transformations. Such requirements directly apply to the toolkit

that will be used to perform these transformations. In this paper,

we examine how Java bytecode transformations, typical for AOP

implementations can be done efficiently, using the ASM

bytecode manipulation framework [1].

Transformations used by general-use AOP frameworks and

similar applications can be categorized, and the common patterns

can be reused to implement specific transformations. These

patterns can also be combined to implement more complex

transformations.

General Terms

Languages, Design, Performance, Experimentation,

Standardization

Keywords

Aspect-Oriented Programming, Java, bytecode, weaving, ASM

1. INTRODUCTION

The ASM bytecode framework was designed at France Telecom

R&D by Eric Bruneton, Romain Lenglet and Thierry Coupaye

[2]. After evaluating several existing frameworks, including

BCEL [3], Serp [4] and JOIE [5], they designed a more efficient

approach, providing better performance and memory foot print.

Today ASM is used in many applications and has become the de-

facto standard for bytecode processing.

The main idea of the ASM API [6] is not to use an object

representation of the bytecode. This made it possible expressing

the same transformations using only a few classes comparing to

approximately 80 classes in Serp and 270 in BCEL API. Those

frameworks create lots of objects during class deserialization,

which takes a lot of time and memory. ASM avoids this overhead

to keep transformation fast and to use very little memory. This is

done by using the Visitor design pattern [7], without representing

The ASM name does not mean anything: it is just a reference to

the keyword in C which allows some functions to be

implemented in assembly language.

the visited tree with objects. Visitors can change call chains and

therefore transform the visited code. Using the Adapter design

pattern [7] visitors can be chained in order to implement complex

transformation from smaller building blocks. A similar approach

is also used in the SAX API for XML processing [8].

ASM hides all the complexity of the serialization and

deserialization of the class bytecode, using the following

techniques:

• Automatic management of the class constant pool,

therefore the user does not have to manipulate indexes

of these constants.

• Automatic management of the class structure, including

annotations, fields, methods, method code and other

standard bytecode attributes.

• Labels are used to manage instruction addresses, so it is

easy to insert new code in between existing instructions

• Computation of maximum stack and local variables, as

well as StackMapFrames

The event-based interaction between event producers and event

consumers is defined by several interfaces: ClassVisitor,

FieldVisitor, MethodVisitor, and AnnotationVisitor. Event

producers, like ClassReader fire visit*() calls to those interfaces.

On the other hand, event receivers like writers (ClassWriter,

FieldWriter, MethodWriter, and AnnotationWriter), adapters

(ClassAdapter and MethodAdapter) or classes from the tree

package (ClassNode, MethodNode, etc) implementing those

interfaces.

The following code demonstrates how this looks from the

developer’s point of view:

ClassReader cr = new ClasReader(bytecode);

ClassWriter cw = new ClassWiter(cr,

ClassWriter.COMPUTE_MAXS |

ClassWriter.COMPUTE_FRAMES);

FooClassAdapter cv = new FooClassAdapter(cw);

cr.accept(cv, 0);

Here ClassReader reads the bytecode. On accept() method call

ClassReader fires all visiting events corresponding to the

bytecode structure. FooClassAdapter will receive those events

and can change the event flow before passing them to the

ClassWriter. Once ClassWriter receive all the events it will have

transformed bytecode. You may notice that the ClassReader

instance is passed to the ClassWriter that allows performance

optimizations based on the assumption that the transformations

mostly add new code.

The following sections will show a number of practical examples

that should help you to better understanding of the ASM

framework.

2. Accessing class data

The visitor-based approach allows capturing class data

incrementally, collecting only the information required for

specific use case without creating and destroying lots of short-

lived objects. Incremental processing allows decisions such as

whether or not part of the class needs to be transformed, skipping

parsing of class parts that don’t need to be transformed.

ASM provide very simple API to support this. First of all there

are several bit-mask flags in the ClassReader.accept() method:

• SKIP_DEBUG – Used to ignore debug info, such as

source file, line number and variable info.

• SKIP_FRAMES – Used to ignore StackMapTable

information used for Java 6 split bytecode verifier.

• EXPAND_FRAMES – Expand the StackMapTable

data, allowing visitor to have information on types of all

local variables and current stack slots.

• SKIP_CODE – Exclude code of all methods from

visiting, while still passing trough method’s and

parameter’s attributes and annotations.

Additionally, the visitor can decide to skip the corresponding

bytecode section it is not interested in. In order to do that,

visitField(), visitMethod() and visitAnnotation() methods that

returns nested visitor can return null. That will indicate to the

bytecode producer to skip the corresponding class element.

When there is no need to read class data, but just the class

hierarchy, ClassReader provides shortcut methods

getSuperName() and getInterfaces() to read super class and

implemented interfaces, respectively.

It is also possible use the tree package of ASM framework to read

the entire class or selected method in memory and change its

structures using DOM-like API. For example:

ClassReader cr = new ClassReader(source);

ClassWriter cw = new ClassWriter();

ClassAdapter ca = new ClassAdapter(cw) {

public MethodVisitor visitMethod(int access,

String name, String desc,

String signature, String[] exceptions) {

final MethodVisitor mv =

super.visitMethod(access,

name, desc, signature, exceptions);

MethodNode mn = new MethodNode(access,

name, desc, signature, exceptions) {

public void visitEnd() {

// transform/analyze this method DOM

accept(mv);

}

};

return mn;

}

};

cr.accept(ca, 0);

The above code will basically suspend passing method events to

the next visitor in the chain (i.e. ClassWriter in this case) until the

visitEnd() event. When visitEnd() is passed, the MethodNode

instance will contain the entire method data. At this point the

method data can be transformed and only after that, finally passed

to the next visitor using the MethodNode.accept() method.

It is worth mentioning that ASM provides several basic Data Flow

Analysis algorithms that work on the tree package and can be

used to analyze selected methods in isolation. The result of such

analysis can be also used for inter-method analysis.

Combining those features it is possible to retrieve required class

information with very controlled memory overhead by making

decisions on the required transformations at load time.

In the next sections we will see concrete examples of the bytecode

transformations typical for AOP.

3. COMMON TRANSFORMATIONS

AOP frameworks that are using load time transformations usually

build their own high-level abstractions about how application

code needs to be transformed. Those abstractions can be

decomposed into smaller building blocks that can be chained

together to achieve the required transformation. Here are most

common use cases:

• Class Transformations

• Introduce Interface

• Add a New Field

• Add a New Method

• Replace Method Body

• Merge Two Classes into One

• Method Transformations

• Insert Code before Method, Constructor or Static

Initializer Execution

• Insert Code before Method Exit

• Replace Field Access

• Replace Method Call

• Inline Method

3.1 Class Transformations

3.1.1 Introducing Interface

This transformation only changes the class information about the

implemented interfaces. We can use simple ClassAdapter for this:

public class InterfaceAdder extends ClassAdapter {

private Set newInterfaces;

public InterfacesAdder(ClassVisitor cv,

Set newInterfaces) {

super(cv);

this.newInterfaces = newInterfaces;

}

public void visit(int version, int access,

String name, String signature,

String superName, String[] interfaces) {

Set ints = new HashSet(newInterfaces);

ints.addAll(Arrays.asList(interfaces));

cv.visit(version, access, name, signature,

superName, (String[]) ints.toArray());

}

Note, the actual methods required to implement the introduced

interfaces must be added with a separate transformation, which

will be discussed shortly.

剩余6页未读，继续阅读

评论收藏

内容反馈

small_warm

粉丝: 13
资源: 22

asm-transformations e文

最新资源

asm-transformations e文

asm-transformations.pdf

asm-util.jar

asm-9.1-API文档-中文版.zip

asm-2.2.3.jar,asm-commons-2.2.3.jar,asm-util-2.2.3.jar,cglib-nodep-2.1_3.jar

asm-all-3.0.jar等jar包

asm-4.2-API文档-中文版.zip

asm-commons-3.3.1.jar

asm-commons

asm-all-5.2.jar

asm-util-6.0.jar

kmod-oracleasm-2.0.6.rh1-3.el6.x86_64.rpm和Oracleasmlib、Oracleasm-support

asm-2.2.3.jar，asm-commons-2.2.3.jar，asm-util-2.2.3.jar

asm-commons-3.2、asm-3.2.jar

cglib-2.2.jar asm-tree.jar asm-commons.jar asm.jar

asm-all-3.2.jar

asm-all-5.0.2-API文档-中文版.zip

开发工具 asm-5.1

升级struts2.3.32 需要的jar：asm-3.3.jar,asm-commons-3.3,asm-tree-3.3.jar

asm-all-5.0.jar

tomcat 8.5.100

基于spring boot的小区物业管理系统源码+论文+答辩ppt

RocketMQ 可视化工具 Dashboard下载

最新Java JDK 8安装版（Windows 64位）

自主研发的软著申请代码文档整理输出工具

Java 面经手册·小傅哥.pdf

BurpLoaderKeygen.jar.zip

java-11 windows-x64 安装包

jdk1.8 - 8u421 - windows

2024最强Java面试八股文

最新资源