Pimcore内容管理框架.7z资源-CSDN下载

共8544个文件

php：3771个

png：2196个

gif：771个

20 浏览量 2023-03-15 08:13:10 上传评论收藏 13.12MB 7Z 举报

Pimcore是一款强大的开源内容管理框架（CMF），它提供了丰富的功能来构建复杂的Web应用程序，尤其是对于内容管理和数字资产管理有着出色的表现。这个压缩包“Pimcore内容管理框架.7z”很可能包含了Pimcore的源代码，允许开发者深入理解其工作原理并进行自定义开发。 1. **Pimcore简介** Pimcore是一个基于PHP的开放源码平台，它集成了内容管理系统（CMS）、数字资产管理（DAM）、产品信息管理（PIM）和电子商务等功能。它的设计理念是提供一个灵活、可扩展的架构，以便适应各种业务需求。 2. **内容管理系统（CMS）** Pimcore的CMS部分提供了直观的用户界面，用于创建、编辑和发布网页内容。它支持多语言、多站点管理，以及动态内容和模板系统，使非技术人员也能轻松管理网站内容。 3. **数字资产管理（DAM）** Pimcore的DAM模块允许组织存储、组织和分发大量的数字资产，如图片、视频、文档等。它支持元数据管理，提供版本控制和权限设置，确保资产的安全和有效利用。 4. **产品信息管理（PIM）** Pimcore的PIM功能使得商品数据的集中管理变得简单，可以处理多语言、多渠道的产品数据。它有助于提高数据质量和一致性，为电子商务和其他产品相关的应用提供强大支持。 5. **电子商务集成** Pimcore具有与各种电子商务平台集成的能力，可以构建全功能的在线商店。它支持订单管理、库存控制、购物车和支付网关集成等关键功能。 6. **源码分析** 通过压缩包中的源码，开发者可以了解Pimcore的架构设计，包括MVC模式的应用、数据库交互、模板引擎和插件系统。这有助于自定义开发，优化性能，或扩展Pimcore的功能。 7. **技术栈** Pimcore基于Symfony PHP框架，利用Zend Framework的部分组件，采用MySQL或PostgreSQL作为数据库，支持前端技术如HTML5、CSS3和JavaScript（包括jQuery和Vue.js）。 8. **社区支持和扩展** 作为一个开源项目，Pimcore拥有活跃的开发者社区，提供大量的文档、教程和插件。用户可以通过社区获取帮助，或者贡献自己的代码和解决方案。 9. **安全性** Pimcore遵循最佳安全实践，包括输入验证、SQL注入防护和XSS防御，确保应用程序的安全运行。 10. **部署与维护** Pimcore支持多种部署方式，如本地、云和容器化环境（如Docker）。定期更新和维护是必要的，以确保系统的稳定性和兼容性。 Pimcore内容管理框架为构建复杂的Web应用程序提供了全面的工具集，而这个压缩包提供的源代码对于开发者来说是一份宝贵的资源，可以帮助他们深入了解其内部机制，并根据需要进行定制开发。

资源推荐

资源详情

资源评论

收起资源包目录

Pimcore内容管理框架.7z （8544个子文件）

AUTHORS 303B

build.bat 79B

install-php.cmd 646B

add-environment-variables.cmd 311B

Web.config 595B

ServiceConfiguration.cscfg 469B

ServiceDefinition.csdef 919B

ext-all.css 114KB

ext-all-notheme.css 99KB

editor_ie7.css 47KB

editor_iequirks.css 46KB

editor_ie8.css 46KB

editor_ie.css 45KB

editor_gecko.css 45KB

editor.css 45KB

icons.css 41KB

xtheme-access.css 41KB

xtheme-blue.css 39KB

xtheme-gray.css 38KB

yourtheme.css 38KB

viewer.css 33KB

adminer.css 28KB

admin.css 21KB

fontello.css 18KB

ux-all.css 17KB

dialog_ie7.css 17KB

dialog_ie8.css 16KB

dialog_iequirks.css 16KB

dialog_ie.css 16KB

dialog_opera.css 16KB

dialog.css 15KB

form.css 12KB

grid.css 12KB

editmode.css 9KB

button.css 8KB

panel.css 8KB

tabs.css 8KB

grid.css 7KB

panel-reset.css 7KB

GroupTab.css 6KB

core.css 6KB

toolbar.css 6KB

layout.css 5KB

date-picker.css 5KB

sample.css 5KB

tree.css 5KB

menu.css 4KB

styles.css 4KB

tree.css 4KB

form.css 4KB

window.css 4KB

tree.css 4KB

button.css 4KB

toolbar.css 4KB

tabs.css 3KB

date-picker.css 3KB

editor.css 3KB

tabs.css 3KB

resizable.css 3KB

date-picker.css 3KB

statusbar.css 3KB

form.css 3KB

tabs.css 3KB

styles.css 3KB

toolbar.css 3KB

qtips.css 3KB

form.css 3KB

button.css 3KB

install.css 3KB

button.css 3KB

panel.css 2KB

admin.css 2KB

panel.css 2KB

slider.css 2KB

panel.css 2KB

ext-admin-overwrite.css 2KB

superboxselect.css 2KB

window.css 2KB

menu.css 2KB

window.css 2KB

core.css 2KB

resizable.css 2KB

outputxhtml.css 2KB

core.css 2KB

resizable.css 2KB

menu.css 2KB

list-view.css 2KB

core.css 2KB

RowEditor.css 2KB

box.css 2KB

共 8544 条

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.

评论收藏

内容反馈

BryanDing

粉丝: 1967

Pimcore内容管理框架.7z

Pimcore内容管理框架 2.0.2.zip

pimcore企业内容管理平台框架 v4.4.0 多国语言版.zip

pimcore-kenaz

demo:Pimcore官方演示包-您是Pimcore的新手吗？ 那是您的切入点！ :nerd_face:

pimcore-docker-compose:Pimcore 5的简单Docker-Compose配置

pimcore：开源数字体验平台（DXP，MDMPIM，CDP，DAM，CMSUX和电子商务

pimcore v1.4.1

PimPon:ImportExport Pimcore 后端对象、文档、路由、用户和角色

深入理解Magento详细培训教程

php-cli简介(不会Shell语言一样用Shell)

windows+apche+php+imagick扩展成功安装

pimcore-members：Pimcore对象，资产和文档限制以及前端身份验证

WrapperTags:Pimcore 文档标签的包装器

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

32个uniapp项目源码 涵盖商城团购等

20余套微信小程序源代码（含前端和后端）

chatGPT商业版源码和教程.zip

用C#&HALCON开发的完整视觉检测案例.rar

zxing.delphi是最新3.9.5版，支持到delphi 11.3，好用的条形码与二维码扫描源代码

profinet协议栈源码

碰一碰源码/一键转发/抖音/团购

蓝桥杯第十四届省赛真题源码

MES系统源码C#源码

完整的进销存ERP管理系统源码+小程序

Scratch3.0编程100个实例代码及素材（数学、语文、科学、音乐、游戏、动画）

基于JavaWeb的SSM的音乐网站（源码+数据库+报告）开源项目.zip

小米官网simply.zip

STM32F103C8T6+MPU6050完整工程，可直接编译下载使用

JavaWeb开发实战源码

国产系统deepin。为什么要国产化？国产化意味着什么？（含Deepin系统部分问题解决）

FierceWow.l8o191slj2.cfXTh0p

最新资源

demo:Pimcore官方演示包-您是Pimcore的新手吗？那是您的切入点！ :nerd_face:

32个uniapp项目源码涵盖商城团购等