从方法编译器改造的Java轨迹JIT编译器

需积分: 9 89 浏览量更新于2024-09-15 收藏 349KB PDF 举报

"A Trace-based Java JIT Compiler Retrofitted from a Method-based Compiler" 本文详细介绍了从基于方法的Java即时编译器（method-JIT）改造而成的轨迹即时编译器（trace-JIT）。作者Hiroshi Inoue、Hiroshige Hayashizaki、Peng Wu和Toshio Nakatani分别来自IBM Research - Tokyo和IBM Research - T.J. Watson Research Center。他们的工作主要关注如何将现有的method-JIT转换为更高效的trace-JIT，并展示了这种转换在提升代码质量方面的潜力。一、设计与实现 1. 转换过程：首先，他们分析了method-JIT的架构，识别出可以转化为trace-JIT的关键组件。在保留原有优化策略的基础上，他们扩展了编译范围，从单个方法的编译转变为追踪多个方法执行的连续片段（traces）。 2. 轨迹形成：通过跟踪并记录程序执行路径，trace-JIT能够捕获一段连续的指令序列，这些序列跨越了多个方法调用。这种方法比传统的method-JIT中的方法内联（method inlining）更为强大，因为它能够减少方法调用的开销，并且提供了更多的优化机会。 3. 运行时开销：然而，引入轨迹编译也会带来额外的运行时开销，包括追踪选择、编译以及维护轨迹结构等。尽管如此，由于代码质量的提高，这些开销通常可以通过性能提升来抵消。二、性能比较 1. 代码质量提升：实验结果表明，trace-JIT在大多数情况下能生成质量更高的代码，这得益于更大的编译范围和更有效的优化。 2. 性能表现：整体上，这个trace-JIT实现了与method-JIT相当的性能，有时甚至超越了它。这表明，尽管有额外的运行时成本，但通过扩大编译视图，trace-JIT在很多场景下能够提供更好的执行效率。三、优化策略 1. 轨迹优化：除了减少方法调用开销，trace-JIT还能够进行更复杂的循环展开、死代码消除、分支预测等优化，这些都是在更宽广的上下文中进行的。四、未来工作虽然取得了积极的结果，但作者也指出，进一步的工作可能包括优化轨迹选择策略，以平衡编译开销和性能收益，以及研究如何有效地处理动态语言特性的编译。总结起来，这篇论文提供了一种将传统method-JIT转变为更高效trace-JIT的方法，强调了轨迹编译在扩展编译范围和提高代码质量方面的重要性。尽管存在一定的运行时开销，但trace-JIT的整体性能和优化潜力使其成为Java性能提升的一个有力工具。

exception throws or catches. By abstracting at the level of

execution events, our tracing runtime supports multiple

language runtime systems including the JVM that we describe

in this paper.

Our trace selection algorithm first determines a point to

start a trace (a trace head) and then records the next execution

starting from the trace head as a trace, similar to the well-

known NET (Next Executing Tail) strategy [1]. To focus on the

basic trace-JIT characteristics, we currently collect only linear

traces or cyclic traces (where a cyclic trace has a jump to its

own trace head at the end). Hence we do not have any join

points in our traces except for the trace head of a cyclic trace.

Figure 2 shows examples of a linear trace and a cyclic trace.

To identify a hot trace head, we assign a counter called a

hotness counter for each potential trace head, which includes

the target of a taken backward branch and any bytecode that

immediately follows the exit point of an already formed trace

to achieve sufficiently high coverage for the JIT compiled code.

We manage the information associated with the bytecode

addresses, such as the hotness counter or the compiled code

address, using a globally synchronized hash map called a trace

cache. The trace selection engine increments the hotness

counter when it receives an event for the bytecode address and

it starts recording the execution to form a trace when the

hotness counter reaches a predefined threshold. We used 500 as

the threshold in this paper. For example, a loop head is selected

as a trace head after 500 iterations. We picked the threshold

based on the thresholds used in the baseline method-JIT to start

initial compilation.

In the recording mode, the trace selection engine records all

basic blocks (BBs) executed until one of the trace termination

conditions is satisfied. We terminate a trace when (1) it forms a

cycle in the recording buffer, (2) it executes a backward branch

(even it does not form a cycle), (3) it calls a native (JNI)

method that we cannot include in a trace, (4) it throws an

exception, or (5) the recording buffer becomes full. The default

size of the recording buffer is 128 BBs for one recording. As

we will describe in Section IV, we allow traces to include calls

to a selected set of JNI methods from the Java standard library

to maximize the performance. Calls to other JNI methods will

terminate the recording of a trace. If a trace forms a cycle by

jumping to its trace head, the trace becomes a cyclic trace. We

identify a cyclic execution patterns accurately by checking the

calling context of each BB in the trace [16]. Otherwise, the

trace becomes a linear trace. A trace collected by the selection

engine is sent to a shared waiting queue that is processed by the

compilation thread.

When the compilation thread compiles the trace, it puts the

entry point address of the compiled code in the trace cache.

Once the compiled code address becomes available in the trace

cache, the interpreter transfers control to the entry point of the

compiled code when the execution reaches the head of a trace.

At the exit of the compiled trace, it returns control to the

interpreter or directly dispatches the next compiled trace using

a technique called trace linking [1]. Currently we do not

employ a specialization technique and thus there is at most one

trace starting from the same bytecode address.

B. Trace-based JIT Compiler and Scope Mismatch

We implemented our trace-JIT by enhancing a mature

method-JIT instead of implementing it from scratch. Our trace-

JIT takes a Java bytecode sequence and the originating location

(Java method and bytecode index in the method) for each

bytecode in the trace as input.

In trace-based compilation, a compilation scope probably

does not match the method scope. Thus we need to assume that

local variables and operands in the operand stack may live at

the beginning and the end of the compilation scope, while all

these values must be dead in the method-based compilation.

We call this problem scope mismatch. Scope mismatch is a

large obstacle when implementing a trace-based compiler from

a method-based compiler. For example, the first bytecode in a

trace may require operands on the operand stack, but a

compiler cannot identify the type of the operands because the

value comes from outside the current compilation scope. To

handle problems caused by scope mismatch, we implemented a

helper function that analyzes the bytecode sequence of a

method, regardless of the current compilation scope. The helper

function identifies the type and liveness of operands on stack

and local variables at the specified program location. The

liveness information at compilation scope boundaries obtained

from this helper function is critical for both code generation

and optimization. For example, the IR (Intermediate

Tracing runtime

interpreter

trace (Java bytecode)

trace selection

engine

trace selection

engine

IR generator

optimizers

code generator

trace dispatcher

garbage collector

code cache

class libraries

trace cache

(hash map)

trace cache

(hash map)

(e.g. hotness counter and

compiled code address)

Java VM

JIT compiler

modified component

unmodified component

new component

execution events

compiled code

early redundancy

elimination

early redundancy

elimination

Figure 1. Overview of our trace-JIT system architecture.

stub

entry

exit

stub

exit

the program

may exit from

the trace at

conditional

branch,

virtual call

guard, or

return guard

stub blocks

to restore

JVM state

entry

stub

exit

stub

exit

stub block

for trace exit

caused by an

exception

the program

branches out

from the trace

if an exception

occurs

(a) linear trace

(b) cyclic trace

(consists of 3 BBs) (consists of 2 BBs)

Figure 2. Example of (a) a linear trace and

(b) a cyclic trace. Each box shows a basic block.

剩余10页未读，继续阅读

felixs

粉丝: 158
资源: 18

从方法编译器改造的Java轨迹JIT编译器

Introduction to Compiler Construction in a Java World 无水印pdf

Introduction to Compiler Construction in a Java World

Trace-based JIT简介(对Method JIT的改进)

svelte-kit-with-tailwind-jit-example

web-site-gatsby-07-tailwind-jit

simple-jit-compiler:该项目旨在说明 JIT 编译器开发中使用的机制

socket-lambda-jit-crash

tailwindcss-build-jit-issue:在JIT模式下使用tailwindcss build进行错误演示

--Awesome-NodeJS--:JIT编译JS运行时。 学习快递，考阿，哈皮

svelte-kit-tailwind-jit:SvelteKit和TailwindCSS JIT的实验模板

最新资源

--Awesome-NodeJS--:JIT编译JS运行时。学习快递，考阿，哈皮