基于Vue和HTML的微信端失业保险金申领设计源码资源-CSDN文库

共499个文件

bcmap：168个

properties：124个

png：91个

版权申诉

Vue框架

微信小程序

开发源码

HTML5

CSS3

65 浏览量 2024-09-27 08:55:10 上传评论收藏 13.1MB ZIP 举报

资源推荐

资源详情

资源评论

收起资源包目录

基于Vue和HTML的微信端失业保险金申领设计源码（499个子文件）

.babelrc 202B

UniCNS-UTF8-H.bcmap 52KB

UniCNS-UTF32-H.bcmap 51KB

UniCNS-UTF16-H.bcmap 49KB

UniCNS-UCS2-H.bcmap 47KB

UniGB-UTF8-H.bcmap 46KB

UniGB-UTF32-H.bcmap 45KB

UniGB-UTF16-H.bcmap 43KB

UniGB-UCS2-H.bcmap 42KB

UniJIS2004-UTF8-H.bcmap 41KB

UniJIS-UTF8-H.bcmap 41KB

Adobe-CNS1-UCS2.bcmap 40KB

Adobe-Japan1-UCS2.bcmap 40KB

UniJIS2004-UTF32-H.bcmap 40KB

UniJISX02132004-UTF32-H.bcmap 40KB

UniJIS-UTF32-H.bcmap 40KB

UniJISX0213-UTF32-H.bcmap 40KB

UniJIS2004-UTF16-H.bcmap 39KB

UniJIS-UTF16-H.bcmap 39KB

Adobe-GB1-UCS2.bcmap 33KB

UniKS-UTF8-H.bcmap 27KB

UniKS-UTF32-H.bcmap 26KB

UniKS-UTF16-H.bcmap 26KB

UniKS-UCS2-H.bcmap 25KB

UniJIS-UCS2-H.bcmap 25KB

Adobe-Korea1-UCS2.bcmap 23KB

GBK2K-H.bcmap 19KB

KSC-Johab-H.bcmap 16KB

GBK-EUC-H.bcmap 14KB

GBKp-EUC-H.bcmap 14KB

GBTpc-EUC-H.bcmap 7KB

GBT-EUC-H.bcmap 7KB

GBT-H.bcmap 7KB

HKscs-B5-H.bcmap 4KB

ETHK-B5-H.bcmap 4KB

KSCms-UHC-HW-H.bcmap 3KB

KSCms-UHC-H.bcmap 3KB

NWP-H.bcmap 3KB

HKdla-B5-H.bcmap 3KB

78ms-RKSJ-H.bcmap 3KB

Ext-RKSJ-H.bcmap 2KB

Ext-H.bcmap 2KB

Add-H.bcmap 2KB

HKdlb-B5-H.bcmap 2KB

Add-RKSJ-H.bcmap 2KB

78-EUC-H.bcmap 2KB

78-RKSJ-H.bcmap 2KB

78-H.bcmap 2KB

HKgccs-B5-H.bcmap 2KB

HKm471-B5-H.bcmap 2KB

KSCpc-EUC-H.bcmap 2KB

CNS-EUC-V.bcmap 2KB

KSC-EUC-H.bcmap 2KB

KSC-H.bcmap 2KB

CNS-EUC-H.bcmap 2KB

HKm314-B5-H.bcmap 2KB

ETen-B5-H.bcmap 1KB

B5pc-H.bcmap 1KB

B5-H.bcmap 1KB

90pv-RKSJ-H.bcmap 982B

83pv-RKSJ-H.bcmap 905B

UniJISPro-UTF8-V.bcmap 726B

90ms-RKSJ-H.bcmap 721B

90msp-RKSJ-H.bcmap 715B

CNS1-H.bcmap 706B

UniJISPro-UCS2-HW-V.bcmap 705B

UniJISPro-UCS2-V.bcmap 689B

UniJISX02132004-UTF32-V.bcmap 688B

UniJISX0213-UTF32-V.bcmap 684B

UniJIS2004-UTF8-V.bcmap 682B

UniJIS2004-UTF32-V.bcmap 681B

UniJIS-UCS2-HW-V.bcmap 680B

UniJIS-UTF8-V.bcmap 678B

UniJIS-UTF32-V.bcmap 677B

UniJIS-UCS2-V.bcmap 664B

UniJIS2004-UTF16-V.bcmap 647B

UniJIS-UTF16-V.bcmap 643B

Adobe-GB1-5.bcmap 625B

Adobe-GB1-4.bcmap 601B

EUC-H.bcmap 578B

GBpc-EUC-H.bcmap 557B

H.bcmap 553B

GB-EUC-H.bcmap 549B

RKSJ-H.bcmap 534B

GB-H.bcmap 528B

CNS2-H.bcmap 504B

Adobe-Japan1-6.bcmap 485B

Adobe-GB1-3.bcmap 470B

Adobe-GB1-2.bcmap 465B

Adobe-Japan1-5.bcmap 430B

Adobe-CNS1-6.bcmap 406B

Adobe-CNS1-5.bcmap 406B

Adobe-CNS1-4.bcmap 405B

Adobe-CNS1-3.bcmap 401B

Adobe-Korea1-2.bcmap 391B

Adobe-Korea1-1.bcmap 386B

Adobe-CNS1-2.bcmap 376B

Adobe-CNS1-1.bcmap 371B

Adobe-Japan1-4.bcmap 337B

Adobe-CNS1-0.bcmap 317B

共 499 条

Trace-based Just-in-Time Type Specialization for Dynamic

Languages

Andreas Gal

∗ +

, Brendan Eich

∗

, Mike Shaver

∗

, David Anderson

∗

, David Mandelin

∗

Mohammad R. Haghighat

, Blake Kaplan

∗

, Graydon Hoare

∗

, Boris Zbarsky

∗

, Jason Orendorff

∗

Jesse Ruderman

∗

, Edwin Smith

, Rick Reitmaier

, Michael Bebenita

, Mason Chang

, Michael Franz

Mozilla Corporation

∗

{gal,brendan,shaver,danderson,dmandelin,mrbkap,graydon,bz,jorendorff,jruderman}@mozilla.com

Adobe Corporation

{edwsmith,rreitmai}@adobe.com

Intel Corporation

{mohammad.r.haghighat}@intel.com

University of California, Irvine

{mbebenit,changm,franz}@uci.edu

Abstract

Dynamic languages such as JavaScript are more difﬁcult to com-

pile than statically typed ones. Since no concrete type information

is available, traditional compilers need to emit generic code that can

handle all possible type combinations at runtime. We present an al-

ternative compilation technique for dynamically-typed languages

that identiﬁes frequently executed loop traces at run-time and then

generates machine code on the ﬂy that is specialized for the ac-

tual dynamic types occurring on each path through the loop. Our

method provides cheap inter-procedural type specialization, and an

elegant and efﬁcient way of incrementally compiling lazily discov-

ered alternative paths through nested loops. We have implemented

a dynamic compiler for JavaScript based on our technique and we

have measured speedups of 10x and more for certain benchmark

programs.

Categories and Subject Descriptors D.3.4 [Programming Lan-

guages]: Processors — Incremental compilers, code generation.

General Terms Design, Experimentation, Measurement, Perfor-

mance.

Keywords JavaScript, just-in-time compilation, trace trees.

1. Introduction

Dynamic languages such as JavaScript, Python, and Ruby, are pop-

ular since they are expressive, accessible to non-experts, and make

deployment as easy as distributing a source ﬁle. They are used for

small scripts as well as for complex applications. JavaScript, for

example, is the de facto standard for client-side web programming

Permission to make digital or hard copies of all or part of this work for personal or

classroom use is granted without fee provided that copies are not made or distributed

for proﬁt or commercial advantage and that copies bear this notice and the full citation

on the ﬁrst page. To copy otherwise, to republish, to post on servers or to redistribute

to lists, requires prior speciﬁc permission and/or a fee.

PLDI’09, June 15–20, 2009, Dublin, Ireland.

 2009 ACM 978-1-60558-392-1/09/06. . . $5.00

and is used for the application logic of browser-based productivity

applications such as Google Mail, Google Docs and Zimbra Col-

laboration Suite. In this domain, in order to provide a ﬂuid user

experience and enable a new generation of applications, virtual ma-

chines must provide a low startup time and high performance.

Compilers for statically typed languages rely on type informa-

tion to generate efﬁcient machine code. In a dynamically typed pro-

gramming language such as JavaScript, the types of expressions

may vary at runtime. This means that the compiler can no longer

easily transform operations into machine instructions that operate

on one speciﬁc type. Without exact type information, the compiler

must emit slower generalized machine code that can deal with all

potential type combinations. While compile-time static type infer-

ence might be able to gather type information to generate opti-

mized machine code, traditional static analysis is very expensive

and hence not well suited for the highly interactive environment of

a web browser.

We present a trace-based compilation technique for dynamic

languages that reconciles speed of compilation with excellent per-

formance of the generated machine code. Our system uses a mixed-

mode execution approach: the system starts running JavaScript in a

fast-starting bytecode interpreter. As the program runs, the system

identiﬁes hot (frequently executed) bytecode sequences, records

them, and compiles them to fast native code. We call such a se-

quence of instructions a trace.

Unlike method-based dynamic compilers, our dynamic com-

piler operates at the granularity of individual loops. This design

choice is based on the expectation that programs spend most of

their time in hot loops. Even in dynamically typed languages, we

expect hot loops to be mostly type-stable, meaning that the types of

values are invariant. (12) For example, we would expect loop coun-

ters that start as integers to remain integers for all iterations. When

both of these expectations hold, a trace-based compiler can cover

the program execution with a small number of type-specialized, ef-

ﬁciently compiled traces.

Each compiled trace covers one path through the program with

one mapping of values to types. When the VM executes a compiled

trace, it cannot guarantee that the same path will be followed

or that the same types will occur in subsequent loop iterations.

Hence, recording and compiling a trace speculates that the path and

typing will be exactly as they were during recording for subsequent

iterations of the loop.

Every compiled trace contains all the guards (checks) required

to validate the speculation. If one of the guards fails (if control

ﬂow is different, or a value of a different type is generated), the

trace exits. If an exit becomes hot, the VM can record a branch

trace starting at the exit to cover the new path. In this way, the VM

records a trace tree covering all the hot paths through the loop.

Nested loops can be difﬁcult to optimize for tracing VMs. In

a na

ıve implementation, inner loops would become hot ﬁrst, and

the VM would start tracing there. When the inner loop exits, the

VM would detect that a different branch was taken. The VM would

try to record a branch trace, and ﬁnd that the trace reaches not the

inner loop header, but the outer loop header. At this point, the VM

could continue tracing until it reaches the inner loop header again,

thus tracing the outer loop inside a trace tree for the inner loop.

But this requires tracing a copy of the outer loop for every side exit

and type combination in the inner loop. In essence, this is a form

of unintended tail duplication, which can easily overﬂow the code

cache. Alternatively, the VM could simply stop tracing, and give up

on ever tracing outer loops.

We solve the nested loop problem by recording nested trace

trees. Our system traces the inner loop exactly as the na

ıve version.

The system stops extending the inner tree when it reaches an outer

loop, but then it starts a new trace at the outer loop header. When

the outer loop reaches the inner loop header, the system tries to call

the trace tree for the inner loop. If the call succeeds, the VM records

the call to the inner tree as part of the outer trace and ﬁnishes

the outer trace as normal. In this way, our system can trace any

number of loops nested to any depth without causing excessive tail

duplication.

These techniques allow a VM to dynamically translate a pro-

gram to nested, type-specialized trace trees. Because traces can

cross function call boundaries, our techniques also achieve the ef-

fects of inlining. Because traces have no internal control-ﬂow joins,

they can be optimized in linear time by a simple compiler (10).

Thus, our tracing VM efﬁciently performs the same kind of op-

timizations that would require interprocedural analysis in a static

optimization setting. This makes tracing an attractive and effective

tool to type specialize even complex function call-rich code.

We implemented these techniques for an existing JavaScript in-

terpreter, SpiderMonkey. We call the resulting tracing VM Trace-

Monkey. TraceMonkey supports all the JavaScript features of Spi-

derMonkey, with a 2x-20x speedup for traceable programs.

This paper makes the following contributions:

•

We explain an algorithm for dynamically forming trace trees to

cover a program, representing nested loops as nested trace trees.

•

We explain how to speculatively generate efﬁcient type-specialized

code for traces from dynamic language programs.

•

We validate our tracing techniques in an implementation based

on the SpiderMonkey JavaScript interpreter, achieving 2x-20x

speedups on many programs.

The remainder of this paper is organized as follows. Section 3 is

a general overview of trace tree based compilation we use to cap-

ture and compile frequently executed code regions. In Section 4

we describe our approach of covering nested loops using a num-

ber of individual trace trees. In Section 5 we describe our trace-

compilation based speculative type specialization approach we use

to generate efﬁcient machine code from recorded bytecode traces.

Our implementation of a dynamic type-specializing compiler for

JavaScript is described in Section 6. Related work is discussed in

Section 8. In Section 7 we evaluate our dynamic compiler based on

1 for (var i = 2; i < 100; ++i) {

2 if (!primes[i])

3 continue;

4 for (var k = i + i; i < 100; k += i)

5 primes[k] = false;

6 }

Figure 1. Sample program: sieve of Eratosthenes. primes is

initialized to an array of 100 false values on entry to this code

snippet.

Interpret

Bytecodes

Monitor

Record

LIR Trace

Execute

Compiled Trace

Enter

Compiled Trace

Compile

LIR Trace

Leave

Compiled Trace

loop

edge

hot

loop/exit

abort

recording

ﬁnish at

loop header

cold/blacklisted

loop/exit

compiled trace

ready

loop edge with

same types

side exit to

existing trace

side exit,

no existing trace

Overhead

Interpreting

Native

Symbol Key

Figure 2. State machine describing the major activities of Trace-

Monkey and the conditions that cause transitions to a new activ-

ity. In the dark box, TM executes JS as compiled traces. In the

light gray boxes, TM executes JS in the standard interpreter. White

boxes are overhead. Thus, to maximize performance, we need to

maximize time spent in the darkest box and minimize time spent in

the white boxes. The best case is a loop where the types at the loop

edge are the same as the types on entry–then TM can stay in native

code until the loop is done.

a set of industry benchmarks. The paper ends with conclusions in

Section 9 and an outlook on future work is presented in Section 10.

2. Overview: Example Tracing Run

This section provides an overview of our system by describing

how TraceMonkey executes an example program. The example

program, shown in Figure 1, computes the ﬁrst 100 prime numbers

with nested loops. The narrative should be read along with Figure 2,

which describes the activities TraceMonkey performs and when it

transitions between the loops.

TraceMonkey always begins executing a program in the byte-

code interpreter. Every loop back edge is a potential trace point.

When the interpreter crosses a loop edge, TraceMonkey invokes

the trace monitor, which may decide to record or execute a native

trace. At the start of execution, there are no compiled traces yet, so

the trace monitor counts the number of times each loop back edge is

executed until a loop becomes hot, currently after 2 crossings. Note

that the way our loops are compiled, the loop edge is crossed before

entering the loop, so the second crossing occurs immediately after

the ﬁrst iteration.

Here is the sequence of events broken down by outer loop

iteration:

v0 := ld state[748] // load primes from the trace activation record

st sp[0], v0 // store primes to interpreter stack

v1 := ld state[764] // load k from the trace activation record

v2 := i2f(v1) // convert k from int to double

st sp[8], v1 // store k to interpreter stack

st sp[16], 0 // store false to interpreter stack

v3 := ld v0[4] // load class word for primes

v4 := and v3, -4 // mask out object class tag for primes

v5 := eq v4, Array // test whether primes is an array

xf v5 // side exit if v5 is false

v6 := js_Array_set(v0, v2, false) // call function to set array element

v7 := eq v6, 0 // test return value from call

xt v7 // side exit if js_Array_set returns false.

Figure 3. LIR snippet for sample program. This is the LIR recorded for line 5 of the sample program in Figure 1. The LIR encodes

the semantics in SSA form using temporary variables. The LIR also encodes all the stores that the interpreter would do to its data stack.

Sometimes these stores can be optimized away as the stack locations are live only on exits to the interpreter. Finally, the LIR records guards

and side exits to verify the assumptions made in this recording: that primes is an array and that the call to set its element succeeds.

mov edx, ebx(748) // load primes from the trace activation record

mov edi(0), edx // (*) store primes to interpreter stack

mov esi, ebx(764) // load k from the trace activation record

mov edi(8), esi // (*) store k to interpreter stack

mov edi(16), 0 // (*) store false to interpreter stack

mov eax, edx(4) // (*) load object class word for primes

and eax, -4 // (*) mask out object class tag for primes

cmp eax, Array // (*) test whether primes is an array

jne side_exit_1 // (*) side exit if primes is not an array

sub esp, 8 // bump stack for call alignment convention

push false // push last argument for call

push esi // push first argument for call

call js_Array_set // call function to set array element

add esp, 8 // clean up extra stack space

mov ecx, ebx // (*) created by register allocator

test eax, eax // (*) test return value of js_Array_set

je side_exit_2 // (*) side exit if call failed

...

side_exit_1:

mov ecx, ebp(-4) // restore ecx

mov esp, ebp // restore esp

jmp epilog // jump to ret statement

Figure 4. x86 snippet for sample program. This is the x86 code compiled from the LIR snippet in Figure 3. Most LIR instructions compile

to a single x86 instruction. Instructions marked with (*) would be omitted by an idealized compiler that knew that none of the side exits

would ever be taken. The 17 instructions generated by the compiler compare favorably with the 100+ instructions that the interpreter would

execute for the same code snippet, including 4 indirect jumps.

i=2. This is the ﬁrst iteration of the outer loop. The loop on

lines 4-5 becomes hot on its second iteration, so TraceMonkey en-

ters recording mode on line 4. In recording mode, TraceMonkey

records the code along the trace in a low-level compiler intermedi-

ate representation we call LIR. The LIR trace encodes all the oper-

ations performed and the types of all operands. The LIR trace also

encodes guards, which are checks that verify that the control ﬂow

and types are identical to those observed during trace recording.

Thus, on later executions, if and only if all guards are passed, the

trace has the required program semantics.

TraceMonkey stops recording when execution returns to the

loop header or exits the loop. In this case, execution returns to the

loop header on line 4.

After recording is ﬁnished, TraceMonkey compiles the trace to

native code using the recorded type information for optimization.

The result is a native code fragment that can be entered if the

interpreter PC and the types of values match those observed when

trace recording was started. The ﬁrst trace in our example, T

covers lines 4 and 5. This trace can be entered if the PC is at line 4,

i and k are integers, and primes is an object. After compiling T

TraceMonkey returns to the interpreter and loops back to line 1.

i=3. Now the loop header at line 1 has become hot, so Trace-

Monkey starts recording. When recording reaches line 4, Trace-

Monkey observes that it has reached an inner loop header that al-

ready has a compiled trace, so TraceMonkey attempts to nest the

inner loop inside the current trace. The ﬁrst step is to call the inner

trace as a subroutine. This executes the loop on line 4 to completion

and then returns to the recorder. TraceMonkey veriﬁes that the call

was successful and then records the call to the inner trace as part of

the current trace. Recording continues until execution reaches line

1, and at which point TraceMonkey ﬁnishes and compiles a trace

for the outer loop, T

i=4. On this iteration, TraceMonkey calls T

. Because i=4, the

if statement on line 2 is taken. This branch was not taken in the

original trace, so this causes T

to fail a guard and take a side exit.

The exit is not yet hot, so TraceMonkey returns to the interpreter,

which executes the continue statement.

i=5. TraceMonkey calls T

, which in turn calls the nested trace

. T

loops back to its own header, starting the next iteration

without ever returning to the monitor.

i=6. On this iteration, the side exit on line 2 is taken again. This

time, the side exit becomes hot, so a trace T

23,1

is recorded that

covers line 3 and returns to the loop header. Thus, the end of T

23,1

jumps directly to the start of T

. The side exit is patched so that

on future iterations, it jumps directly to T

23,1

At this point, TraceMonkey has compiled enough traces to cover

the entire nested loop structure, so the rest of the program runs

entirely as native code.

3. Trace Trees

In this section, we describe traces, trace trees, and how they are

formed at run time. Although our techniques apply to any dynamic

language interpreter, we will describe them assuming a bytecode

interpreter to keep the exposition simple.

3.1 Traces

A trace is simply a program path, which may cross function call

boundaries. TraceMonkey focuses on loop traces, that originate at

a loop edge and represent a single iteration through the associated

loop.

Similar to an extended basic block, a trace is only entered at

the top, but may have many exits. In contrast to an extended basic

block, a trace can contain join nodes. Since a trace always only

follows one single path through the original program, however, join

nodes are not recognizable as such in a trace and have a single

predecessor node like regular nodes.

A typed trace is a trace annotated with a type for every variable

(including temporaries) on the trace. A typed trace also has an entry

type map giving the required types for variables used on the trace

before they are deﬁned. For example, a trace could have a type map

(x: int, b: boolean), meaning that the trace may be entered

only if the value of the variable x is of type int and the value of b

is of type boolean. The entry type map is much like the signature

of a function.

In this paper, we only discuss typed loop traces, and we will

refer to them simply as “traces”. The key property of typed loop

traces is that they can be compiled to efﬁcient machine code using

the same techniques used for typed languages.

In TraceMonkey, traces are recorded in trace-ﬂavored SSA LIR

(low-level intermediate representation). In trace-ﬂavored SSA (or

TSSA), phi nodes appear only at the entry point, which is reached

both on entry and via loop edges. The important LIR primitives

are constant values, memory loads and stores (by address and

offset), integer operators, ﬂoating-point operators, function calls,

and conditional exits. Type conversions, such as integer to double,

are represented by function calls. This makes the LIR used by

TraceMonkey independent of the concrete type system and type

conversion rules of the source language. The LIR operations are

generic enough that the backend compiler is language independent.

Figure 3 shows an example LIR trace.

Bytecode interpreters typically represent values in a various

complex data structures (e.g., hash tables) in a boxed format (i.e.,

with attached type tag bits). Since a trace is intended to represent

efﬁcient code that eliminates all that complexity, our traces oper-

ate on unboxed values in simple variables and arrays as much as

possible.

A trace records all its intermediate values in a small activation

record area. To make variable accesses fast on trace, the trace also

imports local and global variables by unboxing them and copying

them to its activation record. Thus, the trace can read and write

these variables with simple loads and stores from a native activation

recording, independently of the boxing mechanism used by the

interpreter. When the trace exits, the VM boxes the values from

this native storage location and copies them back to the interpreter

structures.

For every control-ﬂow branch in the source program, the

recorder generates conditional exit LIR instructions. These instruc-

tions exit from the trace if required control ﬂow is different from

what it was at trace recording, ensuring that the trace instructions

are run only if they are supposed to. We call these instructions

guard instructions.

Most of our traces represent loops and end with the special loop

LIR instruction. This is just an unconditional branch to the top of

the trace. Such traces return only via guards.

Now, we describe the key optimizations that are performed as

part of recording LIR. All of these optimizations reduce complex

dynamic language constructs to simple typed constructs by spe-

cializing for the current trace. Each optimization requires guard in-

structions to verify their assumptions about the state and exit the

trace if necessary.

Type specialization.

All LIR primitives apply to operands of speciﬁc types. Thus,

LIR traces are necessarily type-specialized, and a compiler can

easily produce a translation that requires no type dispatches. A

typical bytecode interpreter carries tag bits along with each value,

and to perform any operation, must check the tag bits, dynamically

dispatch, mask out the tag bits to recover the untagged value,

perform the operation, and then reapply tags. LIR omits everything

except the operation itself.

A potential problem is that some operations can produce values

of unpredictable types. For example, reading a property from an

object could yield a value of any type, not necessarily the type

observed during recording. The recorder emits guard instructions

that conditionally exit if the operation yields a value of a different

type from that seen during recording. These guard instructions

guarantee that as long as execution is on trace, the types of values

match those of the typed trace. When the VM observes a side exit

along such a type guard, a new typed trace is recorded originating

at the side exit location, capturing the new type of the operation in

question.

Representation specialization: objects. In JavaScript, name

lookup semantics are complex and potentially expensive because

they include features like object inheritance and eval. To evaluate

an object property read expression like o.x, the interpreter must

search the property map of o and all of its prototypes and parents.

Property maps can be implemented with different data structures

(e.g., per-object hash tables or shared hash tables), so the search

process also must dispatch on the representation of each object

found during search. TraceMonkey can simply observe the result of

the search process and record the simplest possible LIR to access

the property value. For example, the search might ﬁnds the value of

o.x in the prototype of o, which uses a shared hash-table represen-

tation that places x in slot 2 of a property vector. Then the recorded

can generate LIR that reads o.x with just two or three loads: one to

get the prototype, possibly one to get the property value vector, and

one more to get slot 2 from the vector. This is a vast simpliﬁcation

and speedup compared to the original interpreter code. Inheritance

relationships and object representations can change during execu-

tion, so the simpliﬁed code requires guard instructions that ensure

the object representation is the same. In TraceMonkey, objects’ rep-

resentations are assigned an integer key called the object shape.

Thus, the guard is a simple equality check on the object shape.

Representation specialization: numbers. JavaScript has no

integer type, only a Number type that is the set of 64-bit IEEE-

754 ﬂoating-pointer numbers (“doubles”). But many JavaScript

operators, in particular array accesses and bitwise operators, really

operate on integers, so they ﬁrst convert the number to an integer,

and then convert any integer result back to a double.

Clearly, a

JavaScript VM that wants to be fast must ﬁnd a way to operate on

integers directly and avoid these conversions.

In TraceMonkey, we support two representations for numbers:

integers and doubles. The interpreter uses integer representations

as much as it can, switching for results that can only be represented

as doubles. When a trace is started, some values may be imported

and represented as integers. Some operations on integers require

guards. For example, adding two integers can produce a value too

large for the integer representation.

Function inlining. LIR traces can cross function boundaries

in either direction, achieving function inlining. Move instructions

need to be recorded for function entry and exit to copy arguments

in and return values out. These move statements are then optimized

away by the compiler using copy propagation. In order to be able

to return to the interpreter, the trace must also generate LIR to

record that a call frame has been entered and exited. The frame

entry and exit LIR saves just enough information to allow the

intepreter call stack to be restored later and is much simpler than

the interpreter’s standard call code. If the function being entered

is not constant (which in JavaScript includes any call by function

name), the recorder must also emit LIR to guard that the function

is the same.

Guards and side exits. Each optimization described above

requires one or more guards to verify the assumptions made in

doing the optimization. A guard is just a group of LIR instructions

that performs a test and conditional exit. The exit branches to a

side exit, a small off-trace piece of LIR that returns a pointer to

a structure that describes the reason for the exit along with the

interpreter PC at the exit point and any other data needed to restore

the interpreter’s state structures.

Aborts. Some constructs are difﬁcult to record in LIR traces.

For example, eval or calls to external functions can change the

program state in unpredictable ways, making it difﬁcult for the

tracer to know the current type map in order to continue tracing.

A tracing implementation can also have any number of other limi-

tations, e.g.,a small-memory device may limit the length of traces.

When any situation occurs that prevents the implementation from

continuing trace recording, the implementation aborts trace record-

ing and returns to the trace monitor.

3.2 Trace Trees

Especially simple loops, namely those where control ﬂow, value

types, value representations, and inlined functions are all invariant,

can be represented by a single trace. But most loops have at least

some variation, and so the program will take side exits from the

main trace. When a side exit becomes hot, TraceMonkey starts a

new branch trace from that point and patches the side exit to jump

directly to that trace. In this way, a single trace expands on demand

to a single-entry, multiple-exit trace tree.

This section explains how trace trees are formed during execu-

tion. The goal is to form trace trees during execution that cover all

the hot paths of the program.

Arrays are actually worse than this: if the index value is a number, it must

be converted from a double to a string for the property access operator, and

then to an integer internally to the array implementation.

Starting a tree. Tree trees always start at loop headers, because

they are a natural place to look for hot paths. In TraceMonkey, loop

headers are easy to detect–the bytecode compiler ensures that a

bytecode is a loop header iff it is the target of a backward branch.

TraceMonkey starts a tree when a given loop header has been exe-

cuted a certain number of times (2 in the current implementation).

Starting a tree just means starting recording a trace for the current

point and type map and marking the trace as the root of a tree. Each

tree is associated with a loop header and type map, so there may be

several trees for a given loop header.

Closing the loop. Trace recording can end in several ways.

Ideally, the trace reaches the loop header where it started with

the same type map as on entry. This is called a type-stable loop

iteration. In this case, the end of the trace can jump right to the

beginning, as all the value representations are exactly as needed to

enter the trace. The jump can even skip the usual code that would

copy out the state at the end of the trace and copy it back in to the

trace activation record to enter a trace.

In certain cases the trace might reach the loop header with a

different type map. This scenario is sometime observed for the ﬁrst

iteration of a loop. Some variables inside the loop might initially be

undeﬁned, before they are set to a concrete type during the ﬁrst loop

iteration. When recording such an iteration, the recorder cannot

link the trace back to its own loop header since it is type-unstable.

Instead, the iteration is terminated with a side exit that will always

fail and return to the interpreter. At the same time a new trace is

recorded with the new type map. Every time an additional type-

unstable trace is added to a region, its exit type map is compared to

the entry map of all existing traces in case they complement each

other. With this approach we are able to cover type-unstable loop

iterations as long they eventually form a stable equilibrium.

Finally, the trace might exit the loop before reaching the loop

header, for example because execution reaches a break or return

statement. In this case, the VM simply ends the trace with an exit

to the trace monitor.

As mentioned previously, we may speculatively chose to rep-

resent certain Number-typed values as integers on trace. We do so

when we observe that Number-typed variables contain an integer

value at trace entry. If during trace recording the variable is unex-

pectedly assigned a non-integer value, we have to widen the type

of the variable to a double. As a result, the recorded trace becomes

inherently type-unstable since it starts with an integer value but

ends with a double value. This represents a mis-speculation, since

at trace entry we specialized the Number-typed value to an integer,

assuming that at the loop edge we would again ﬁnd an integer value

in the variable, allowing us to close the loop. To avoid future spec-

ulative failures involving this variable, and to obtain a type-stable

trace we note the fact that the variable in question as been observed

to sometimes hold non-integer values in an advisory data structure

which we call the “oracle”.

When compiling loops, we consult the oracle before specializ-

ing values to integers. Speculation towards integers is performed

only if no adverse information is known to the oracle about that

particular variable. Whenever we accidentally compile a loop that

is type-unstable due to mis-speculation of a Number-typed vari-

able, we immediately trigger the recording of a new trace, which

based on the now updated oracle information will start with a dou-

ble value and thus become type stable.

Extending a tree. Side exits lead to different paths through

the loop, or paths with different types or representations. Thus, to

completely cover the loop, the VM must record traces starting at all

side exits. These traces are recorded much like root traces: there is

a counter for each side exit, and when the counter reaches a hotness

threshold, recording starts. Recording stops exactly as for the root

trace, using the loop header of the root trace as the target to reach.

评论收藏

内容反馈

版权申诉

lly202406

粉丝: 3011
资源: 5529

基于Vue和HTML的微信端失业保险金申领设计源码

VB失业保险管理信息系统(源代码+系统).zip

基于Vue.js的微信公众号后台前端管理界面设计源码

基于Vue框架的微信公众号保险行业设计源码

基于Vue的uniapp微信小程序前端初版本设计源码

基于VUE和SpringBoot的微信小程序商城的设计与实现(论文+源码)-kaic.zip

基于Vue的rqdrH5微信端达人小程序设计源码

基于Vue和JavaScript的微信端人事档案个人源码设计

基于PHP和Vue的企业微信SCRM系统设计源码

基于Vue框架的微信招聘系统设计源码

基于Vue和微信小程序的书店商城设计源码

基于Vue和微信小程序的借书系统设计源码

基于Vue的meedu微信小程序设计源码

基于Vue和微信小程序的二手交易uniapp前端设计源码

vue实现的微信机器人聊天功能案例【附源码下载】

基于Vue3和微信小程序的校园跑腿系统设计源码

基于Vue框架的微信评优购功能设计源码

一款基于Vue2的仿微信WebApp

基于Vue和JavaScript的微信小程序在线答题系统设计源码

基于vue的订餐微信小程序springboot后端源码案例设计.zip

基于Vue框架开发的校园零食商铺微信端设计源码

基于Vue和微信小程序的固定资产设备管理系统移动端设计源码

基于Vue和微信小程序的租房小程序设计源码

Vuewebpack微信端单页

基于Vue框架和微信小程序的LandLease土地租借app设计源码

基于uniapp和Vue框架的微信社区物业管理小程序设计与开发源码

微信小程序基于Nodejs和Vue3开发的外卖点餐系统源码+sql数据库(课程设计).zip

html5微信小游戏源码 猫咪游戏源码（仅用于参考）

基于Vue和微信小程序的孔云二手车交易平台设计源码

基于Java及Vue.js的微信小程序外卖点餐系统设计源码

vue3,基于最新Vue3+Electron开发仿微信QQ桌面端聊天实例。

最新资源

html5微信小游戏源码猫咪游戏源码（仅用于参考）