1. JavaScript engines how do they even? | Franziska Hinkelmann

1. 프란치스카 힌켈만 | 도대체 자바스크립트 엔진은 어떻게 작동하나요? 원본 유튜브 영상
2. 아래 내용은 위 영상 스크립트를 기계번역한 내용입니다.
3. 이 글의 다음 글

Franziska Hinkelmann - JavaScript engines how do they even?

FRANZISKA: Good morning, are you pumped about low-level JavaScript stuff. That’s what we are going to do now.

프란치스카: 좋은 아침입니다. 저수준(JavaScript 엔진 내부) JavaScript에 대해 흥미가 있나요? 오늘 우리는 그것에 대해 이야기할 것입니다.

I’m Franziska Hinkelmann on the V8 team, in Munich, not that far away.

저는 뮌헨에 있는 V8 팀의 프란치스카 힌켈만입니다.

V8 is being developed in Germany for the most part.

V8 엔진은 대부분 독일에서 개발되고 있습니다.

V8 is the JavaScript engine, and my work focuses a lot on performance optimisations for ES6 and ES6 next features and I talk to you about JavaScript engines now.

V8은 JavaScript 엔진이며, 저는 주로 ES6 및 향후 ES6 기능의 성능 최적화에 집중하고 있습니다. 이제 JavaScript 엔진에 대해 이야기하겠습니다.

Why would you care about JavaScript engines?

JavaScript 엔진에 관심을 가져야 하는 이유는 무엇일까요?

Well, if you have any JavaScript source code and you run it, it’s always the engine that runs it for you.

JavaScript 코드가 있으면, 그것을 실행하는 것은 항상 JavaScript 엔진입니다.

It doesn’t matter if you run it in the browser, or Node.js, or an IoT device,

브라우저에서 실행하든, Node.js에서 실행하든, IoT 장치에서 실행하든 상관없습니다.

To go from something you write to executing that, that’s what the engines are doing.

우리가 작성한 JavaScript 코드를 실행 가능한 상태로 변환하는 것이 엔진의 역할입니다.

JavaScript engines are the heart of everything that we do.

JavaScript 엔진은 우리가 하는 모든 작업의 핵심입니다.

JavaScript engines have evolved a lot in the last 22 years.

JavaScript 엔진은 지난 22년 동안 엄청난 발전을 이루었습니다.

We can run massive complex frameworks and enterprise Node.js services and there is a lot of cool technology in JavaScript engines.

현재 우리는 복잡한 프레임워크나 엔터프라이즈급 Node.js 서비스를 실행할 수 있으며, JavaScript 엔진에는 많은 흥미로운 기술이 포함되어 있습니다.

I hope in the next 20 minutes to give you a bit of an idea what’s happening inside those engines,

앞으로 20분 동안, JavaScript 엔진 내부에서 어떤 일이 일어나는지에 대한 개념을 설명해 드리겠습니다.

What is making your code run so fast?

어떤 기술이 여러분의 JavaScript 코드를 빠르게 실행하게 만드는지 알아보겠습니다.

I will be talking a little bit about performance,

또한 성능 최적화에 대해서도 이야기할 것입니다.

And I just want to point out when I talk about performance,

제가 여기서 성능이라고 말할 때,

I mean specifically only JavaScript performance,

JavaScript 자체의 실행 성능을 의미합니다.

Like computing and running actual JavaScript.

즉, JavaScript 코드의 실행 속도와 관련된 부분만 다룰 것입니다.

I’m not talking about all the other things that are super important for performance like DOM and rendering and network latency.

DOM, 렌더링, 네트워크 지연 시간 등의 성능 요소는 여기서 다루지 않습니다.

When I say performance, I mean computing and running JavaScript.

제가 말하는 성능은 JavaScript 실행 성능을 의미합니다.

JavaScript engines in different environments

다양한 환경에서의 JavaScript 엔진

There are several JavaScript engines,

JavaScript 엔진은 여러 가지가 있습니다.

All the major browsers have their own JavaScript engine,

모든 주요 브라우저는 자체 JavaScript 엔진을 가지고 있습니다.

And it is really good that there are several engines because more engines mean competition.

여러 개의 JavaScript 엔진이 존재하는 것은 좋은 일입니다. 엔진 간의 경쟁이 생기기 때문입니다.

Competition really means better performance and better adherence to the standard.

경쟁이 있으면 성능이 향상되고 표준을 더 잘 준수하게 됩니다.

In the major browsers, just to drop a few names,

주요 브라우저의 JavaScript 엔진을 몇 가지 예로 들면,

SpiderMonkey is in Firefox by Mozilla and V8 is in Chrome.

Mozilla의 Firefox에는 SpiderMonkey가 있고, Chrome에는 V8이 있습니다.

If you run Node.js, you know you need an engine.

Node.js를 실행하려면 JavaScript 엔진이 필요하다는 것을 알고 계실 겁니다.

By default, Node.js comes with V8 but there is a ChakraCore build of Node.js,

기본적으로 Node.js는 V8을 사용하지만, ChakraCore를 사용하는 Node.js 빌드도 있습니다.

And there you get Node.js with a Microsoft Chakra engine,

이 빌드를 사용하면 Microsoft의 Chakra 엔진과 함께 Node.js를 실행할 수 있습니다.

And there is a SpiderNode project using SpiderMonkey.

또한, SpiderMonkey를 사용하는 SpiderNode 프로젝트도 존재합니다.

Again, if you’re working on IoT, if you work on small devices,

한편, IoT나 소형 장치에서 작업하는 경우에는,

You might want to trade in performance for memory size.

성능을 조금 희생하더라도 메모리 사용량을 줄이는 것이 중요할 수 있습니다.

The performance on the browsers is fast, but they take up a lot of memory.

브라우저에서 실행되는 JavaScript 엔진은 빠르지만, 많은 메모리를 소비합니다.

On IoT devices, you can take smaller engines somewhat slower but they fit, like Duktape or JerryScript.

IoT 기기에서는 Duktape나 JerryScript와 같은 가벼운 JavaScript 엔진을 사용할 수도 있습니다.

How ECMAScript evolves

ECMAScript는 어떻게 발전하는가?

The ECMAScript standard is designed by the TC39 committee.

ECMAScript 표준은 TC39 위원회에서 설계합니다.

They discuss additions and changes to the language and formalise it as a standard,

이 위원회는 언어의 추가 기능과 변경 사항을 논의하고 이를 공식 표준으로 만듭니다.

And then we engine implementers implement those standards to give you JavaScript.

그런 다음, JavaScript 엔진 개발자들이 이 표준을 구현하여 실제 JavaScript 엔진을 개발합니다.

That’s really cool because we have a TC39 panel here this afternoon,

오늘 오후에는 TC39 패널 토론이 있을 예정입니다.

So some committee members are here to answer your questions,

TC39 위원회 멤버들이 참석하여 여러분의 질문에 답변해 줄 것입니다.

And they still take questions, so you can tweet some questions for the panel this afternoon.

지금도 질문을 받고 있으니, 궁금한 점이 있으면 트위터를 통해 질문을 남기시면 됩니다.

If you want to know what is happening in the language,

JavaScript 언어가 어떻게 변화하고 있는지 알고 싶다면,

What is the take on a few changes, like that.

어떤 변화가 논의되고 있는지 관심을 가져보세요.

JavaScript는 표준이다

All right, so JavaScript is a standard.

좋습니다. JavaScript는 하나의 표준입니다.

We implement that.

우리는 이 표준을 구현합니다.

And the engine is the thing responsible for using the rules on the standard and then to run your JavaScript.

그리고 JavaScript 엔진은 이 표준의 규칙을 적용하고 JavaScript 코드를 실행하는 역할을 합니다.

JavaScript의 동적 타이핑

What is a really cool thing about JavaScript, besides the awesome community and JSConf?

JavaScript의 멋진 점은 무엇일까요? (커뮤니티와 JSConf 외에도)

One thing that I think is really cool is that if you write JavaScript code, and you have variables, you can just say var x = something.

JavaScript에서 정말 멋진 점 중 하나는 변수를 선언할 때 var x = something처럼 간단하게 쓸 수 있다는 것입니다.

You don’t have to worry about what that x actually is.

그리고 x가 정확히 어떤 타입인지 걱정할 필요가 없습니다.

You can use var or const but you don’t have to distinguish upfront if you have a number, a string, or an array.

var 또는 const를 사용할 수 있으며, 그것이 숫자인지, 문자열인지, 배열인지 미리 정할 필요가 없습니다.

If you have ever written C++, the rules are really, really strict,

하지만 C++을 작성해 본 적이 있다면, 규칙이 매우 엄격하다는 것을 알 것입니다.

And you first have to figure out and read up a lot about integers just to get your first “hello world” program running.

심지어 단순한 “Hello World” 프로그램을 실행하기 위해서도 정수 타입 등에 대해 미리 알아야 합니다.

If you write C++ and want to define a variable that values 17,

C++에서 값을 17로 설정하는 변수를 정의하려면,

You have to specify and know what you want to specify.

어떤 타입을 사용할지 명확하게 지정해야 합니다.

In this case, I’m specifying an integer which can be a whole number, positive or negative.

이 경우, 정수형(integer) 변수를 사용한다고 명시해야 합니다. 정수는 양수 또는 음수가 될 수 있습니다.

They can only be - within a certain range, so, if your number gets too big, it doesn’t fit into an integer any more.

정수형 변수는 특정 범위 내에서만 값을 가질 수 있으며, 너무 큰 숫자는 정수형 변수에 저장할 수 없습니다.

If you write JavaScript, don’t care about any of that.

그러나 JavaScript에서는 이러한 것들을 전혀 신경 쓸 필요가 없습니다.

That makes it really simple for us.

이것이 JavaScript를 쉽게 만드는 요소 중 하나입니다.

We don’t have to worry about this.

우리는 이러한 타입을 신경 쓸 필요가 없습니다.

It makes it easy to get started, it makes it easier to explain it, it makes prototyping usually faster,

그렇기 때문에 JavaScript는 배우기 쉽고, 설명하기도 쉬우며, 프로토타이핑(시제품 개발) 속도가 빠릅니다.

So that’s a really cool thing for a language.

이것이 JavaScript 같은 언어가 가지는 장점 중 하나입니다.

And we call this the language is dynamically typed,

이러한 특징을 우리는 동적 타이핑(Dynamically Typed) 이라고 부릅니다.

So a language like C++ where you have to define types is considered statically typed.

C++처럼 변수를 정의할 때 타입을 지정해야 하는 언어는 정적 타이핑(Statically Typed) 언어라고 합니다.

JavaScript 객체의 유연성

It is not only about the basic types,

JavaScript의 동적 타이핑은 기본적인 데이터 타입에만 적용되는 것이 아닙니다.

Strings where you think you can figure out where they are and say not much more work.

문자열 같은 기본적인 데이터 타입은 비교적 다루기 쉽습니다.

This is for more complex objects.

그러나 동적 타이핑은 더 복잡한 객체(Object) 에도 적용됩니다.

When you have any objects in JavaScript, you can add and delete properties as you wish, as you need,

JavaScript의 객체는 필요에 따라 속성을 자유롭게 추가하고 삭제할 수 있습니다.

You don’t have to make that clear beforehand.

그리고 이러한 속성을 미리 정의할 필요도 없습니다.

So this object here as the properties x and y,

예를 들어, 아래의 객체는 x와 y 속성을 가지고 있습니다.

But if needed, it can delete a property, it can add a property.

필요하면 속성을 삭제하거나 추가할 수도 있습니다.

I have access to all the properties on the prototype chain which I can also change.

또한, 해당 객체의 프로토타입 체인에 존재하는 모든 속성에 접근할 수 있으며, 이를 변경할 수도 있습니다.

So, that’s something that makes it easy to work with objects,

이러한 유연성 덕분에 JavaScript 객체를 다루는 것이 매우 쉽습니다.

And sometimes, it would be even impossible to specify beforehand what exactly your object is like.

그리고 때로는 객체가 어떤 속성을 가질지 미리 정의하는 것이 불가능한 경우도 있습니다.

If you get a bunch of JSON over the net and turn it into an object,

예를 들어, 네트워크를 통해 JSON 데이터를 받아서 객체로 변환한다고 가정해 봅시다.

Sometimes, you don’t know actually what the properties will be.

이때, 해당 객체가 어떤 속성을 가질지는 사전에 알 수 없습니다.

For us as developers, that’s super useful.

개발자로서 이러한 동적 특성은 매우 유용합니다.

It makes it a little bit easier.

코드를 훨씬 더 쉽게 작성할 수 있습니다.

컴파일러 입장에서의 문제점

If you’re a compiler, though, this is not good,

그러나 JavaScript 컴파일러 입장에서는 이러한 동적 특성이 문제가 됩니다.

Because you give so little information to the compiler,

JavaScript 코드는 컴파일러에게 너무 적은 정보를 제공합니다.

The compilers have a hard time generating machine code which is fast if they have no information.

그렇기 때문에, 컴파일러는 빠른 기계어(machine code)를 생성하는 데 어려움을 겪습니다.

That’s why in C++ you specify all that,

이것이 C++에서 미리 모든 타입을 지정해야 하는 이유입니다.

Because the compiler needs this information upfront so it can compile your code into an executable.

C++ 컴파일러는 사전에 이러한 정보를 알아야만 최적화된 실행 파일을 생성할 수 있습니다.

C++ is statically typed not to make it hard for developers,

C++이 정적 타입을 강제하는 이유는 개발자를 어렵게 만들기 위해서가 아닙니다.

Because that allows you to generate fast machine code when you compile C++.

정적 타입을 통해 C++ 컴파일러는 빠른 기계어 코드 를 생성할 수 있습니다.

그렇다면 JavaScript는 어떻게 빠를까?

But now JavaScript is pretty fast, right?

그렇다면 JavaScript는 왜 그렇게 빠를까요?

We have huge libraries, huge frameworks,

현재 우리는 대규모 JavaScript 라이브러리와 프레임워크를 사용하고 있습니다.

We run all these JavaScript tools to transpile our code.

그리고 JavaScript 코드를 변환(transpile)하는 다양한 도구들도 사용하고 있습니다.

JavaScript is really fast, even though it is dynamically typed,

JavaScript는 동적 타입을 가지면서도 매우 빠른 속도로 실행됩니다.

And we have all this freedom when we are using objects and types.

객체와 타입을 자유롭게 사용할 수 있는데도 불구하고, 여전히 성능이 뛰어납니다.

JavaScript 엔진이 빠른 이유: JIT (Just-In-Time) 컴파일

And the trick that all modern JavaScript engines use is so-called Just-In-Time compilation, abbreviated as JIT compilation, which means “just in time”.

모든 최신 JavaScript 엔진이 사용하는 핵심 기술은 JIT(Just-In-Time) 컴파일입니다. JIT는 “적시에(Just in Time)” 컴파일한다는 의미입니다.

What that means is we’re not first compiling ahead of time, finishing a compilation, and then running the code,

JIT 컴파일이란 코드를 미리 컴파일하고 실행하는 것이 아니라,

We are mixing these two steps together and we’re using information from running the code to recompiling the code.

코드를 실행하면서 동시에 컴파일하는 방식을 의미합니다.

So we are compiling the source code just in time as we need it, we collect some information when we run it, and then we recompile this source code.

즉, 필요할 때 소스 코드를 즉시 컴파일(JIT) 하고, 실행 중 수집한 정보를 바탕으로 코드를 다시 컴파일합니다.

If you think about C++ again, which is compiled ahead of time, it is two separate steps.

반면 C++ 같은 정적 언어에서는 컴파일과 실행이 별도의 과정으로 나뉘어 있습니다.

You first compile it, you get an executable, and then you run that executable.

C++은 먼저 코드를 컴파일해서 실행 파일을 생성한 후, 그 실행 파일을 실행합니다.

In JavaScript, that is one step.

하지만 JavaScript에서는 컴파일과 실행이 하나의 과정으로 이루어집니다.

If you start a Node.js process, you say node server.js,

예를 들어 node server.js 같은 명령어를 실행하면,

It is all together because compilation and execution go at the same time and there is feedback going back and forth to speed up the execution.

컴파일과 실행이 동시에 진행되며, 실행 과정에서 얻은 정보를 바탕으로 성능 최적화를 수행합니다.

JavaScript 엔진의 다중 컴파일러 구조

What modern engines have is they don’t have one compiler, they have at least two compilers, where one of them is an optimising compiler.

최신 JavaScript 엔진들은 하나의 컴파일러가 아니라 두 개 이상의 컴파일러를 사용합니다. 그중 하나는 최적화 컴파일러(Optimising Compiler) 입니다.

The main concept I want you to take away here is we have an optimising compiler that is recompiling hot functions,

여기서 중요한 개념은 “핫 함수(hot function)” 입니다.

So a function that you’re using a lot, that is worth speeding up, is considered hot,

자주 실행되는 함수(핫 함수)는 속도를 높일 가치가 있는 함수로 간주됩니다.

That is recompiled by the optimising compiler, which means we compile the code, we run it a few times, we collect information about the types,

이러한 핫 함수는 최적화 컴파일러가 다시 컴파일합니다. 실행 중 수집한 타입 정보를 활용하여 더 빠른 코드로 변환합니다.

And then we say, “Oh, this function is hot, let’s make it faster by using the information that we have gathered so far.”

“이 함수가 자주 실행되므로, 수집한 정보를 바탕으로 더욱 빠르게 최적화하자!“라는 방식으로 동작합니다.

JavaScript 엔진의 최적화 및 디옵티마이제이션 (De-optimisation)

So when we’re recompiling, when we’re optimising, we’re recompiling assuming that we will see similar types as before,

JavaScript 엔진은 기존에 실행된 타입 정보를 바탕으로 최적화된 코드를 생성합니다.

So we bake in this information in the optimised machine code.

즉, 최적화된 기계어 코드에 이전 실행에서 수집한 타입 정보를 반영합니다.

Now, since JavaScript is dynamically typed, no-one is forcing you to keep that same type,

그러나 JavaScript는 동적 타이핑 언어이므로, 같은 함수라도 항상 동일한 타입을 받는다는 보장은 없습니다.

And you can change the kind of inputs you give to your functions,

함수에 전달하는 인자의 타입을 언제든지 변경할 수 있습니다.

So it might happen that, at some point, you run this optimised function on a different kind of object,

그렇기 때문에, 최적화된 함수가 예상과 다른 객체를 받는 경우가 발생할 수 있습니다.

And then you have to de-optimise,

이 경우 엔진은 디옵티마이제이션(De-optimisation, 역최적화) 을 수행해야 합니다.

You can’t use this optimised code for that, and you fall back to the baseline compiler.

즉, 최적화된 코드를 사용할 수 없게 되며, 기본 컴파일러(Baseline Compiler) 로 돌아가야 합니다.

So, compile, run a few times, optimise, assuming certain conditions, run the optimised code, if the conditions fail, go back to the basic code.

JavaScript 엔진의 동작 방식은 다음과 같습니다: 컴파일 → 실행 → 최적화 → 최적화된 코드 실행 → 조건 불일치 시 디옵티마이제이션

JavaScript 엔진의 내부 구조 (V8 예시)

Now, so you start with JavaScript source code,

자, 이제 JavaScript 소스 코드가 어떻게 처리되는지 살펴봅시다.

Then the parser generates an abstract syntax tree.

먼저, 파서(Parser) 가 소스 코드를 분석하여 추상 구문 트리(Abstract Syntax Tree, AST) 를 생성합니다.

I will not talk about the parser because my co-worker Marja will tell you how we parse JavaScript and how you can write it to make it a little faster.

(파서에 대한 자세한 내용은 V8 팀의 동료인 Marja가 다룰 예정입니다.)

The source code is consumed by the parser and then we generate an abstract syntax tree.

즉, JavaScript 엔진은 소스 코드를 AST로 변환하는 과정부터 시작합니다.

Then a compiler is using that abstract syntax tree to make the machine code.

그다음 컴파일러가 AST를 이용하여 기계어 코드(machine code)를 생성합니다.

We collect the information and pass it on to the optimising compiler to generate faster machine code.

그리고 실행 중 수집한 정보를 활용하여 최적화된 기계어 코드를 생성합니다.

Every once in a while, we have to bail out, de-optimised,

그러나 최적화가 실패하는 경우 디옵티마이제이션(역최적화) 을 수행해야 합니다.

Do an OSI exit to go back to the slower baseline machine code.

즉, OSR(Optimised Code Slow Exit) 를 통해 최적화된 코드에서 기본 코드로 되돌아갑니다.

In the V8 engine, the baseline compiler is an interpreter called Ignition,

V8 엔진에서는 기본 컴파일러로 Ignition 이라는 인터프리터를 사용합니다.

And the optimising compiler is called TurboFan.

최적화 컴파일러는 TurboFan 이라고 불립니다.

If you hear about them not in relation to cars, it is about the compiler pipeline in V8!

(“Ignition”과 “TurboFan”은 자동차 엔진이 아니라 V8의 컴파일러 파이프라인 입니다!)

다른 JavaScript 엔진과 비교

In SpiderMonkey, the optimising compiler is Ironmonkey,

Firefox의 SpiderMonkey 엔진에서는 최적화 컴파일러로 IronMonkey 를 사용합니다.

And there are a few more around.

그리고 다른 엔진들도 다양한 최적화 컴파일러를 가지고 있습니다.

For Safari, they don’t have one optimising compiler but two,

예를 들어, Safari의 JavaScriptCore 엔진에는 두 개의 최적화 컴파일러가 존재합니다.

A low-level interpreter and a DFG optimising compiler and B3.

Safari는 저수준 인터프리터, DFG(데이터 흐름 그래프) 최적화 컴파일러, 그리고 B3 최적화 컴파일러를 사용합니다.

And Chakra also has an optimising compiler.

Microsoft의 Chakra 엔진에도 최적화 컴파일러가 포함되어 있습니다.

자바스크립트 엔진의 최적화 방식과 동작 원리

The optimising compiler uses previously seen type information. 최적화 컴파일러는 이전에 실행된 타입 정보를 활용합니다.

If you change your objects all the time, then we cannot generate good optimised code, 하지만 객체의 속성이나 구조가 계속 바뀐다면, 최적화된 코드를 생성할 수 없습니다.

Or if you’ve generated, you have to de-optimise a lot. 또는 최적화가 이루어지더라도, 디옵티마이제이션(역최적화) 이 자주 발생할 것입니다.

De-optimisation always means a small performance hit. 디옵티마이제이션은 항상 성능 저하를 초래합니다.

자바스크립트 최적화 예제: 객체 속성 접근

From the high-level concept, and now I want to show you a concrete example. 지금까지 설명한 개념을 바탕으로, 구체적인 예제를 살펴보겠습니다.

I’m going to show you the optimised machine code for this on an Intel processor. 이제 Intel 프로세서에서 실행되는 최적화된 기계어 코드(Assembly Code) 를 보여드리겠습니다.

I’m using a very simple example. 매우 간단한 예제를 사용하겠습니다.

It is a load function that takes a parameter and all it does is return object.x. 이 예제에서는 load 함수가 매개변수를 받아서 object.x 속성을 반환합니다.

Property access in JavaScript is fairly complicated for the compiler, 하지만 객체의 속성 접근(Object Property Access) 은 컴파일러 입장에서 매우 복잡한 연산입니다.

Because if you have an object that a compiler doesn’t know anything about it and you want x, 왜냐하면, 컴파일러는 객체의 구조를 사전에 알 수 없기 때문입니다.

You don’t know where is this x? 즉, 속성 x가 어디에 저장되어 있는지 알 수 없습니다.

Does this object have an x? 해당 객체가 x 속성을 정말 가지고 있는지 확인해야 합니다.

Is it maybe under the prototype chain? 혹시 프로토타입 체인(Prototype Chain) 에서 x 속성을 상속받고 있는지 검토해야 합니다.

How are the properties stored for the object? 객체 속성들이 메모리에 어떻게 저장 되어 있는지 파악해야 합니다.

Where in the memory is the value for x? 메모리에서 x의 실제 위치(Address) 는 어디인지 찾아야 합니다.

객체 내부의 타입 변환 (Hidden Class Transitions)

We represent object types incrementally by transitioning for every property to a new type. V8 엔진은 객체 타입(Object Shape) 을 점진적으로 변경하며 추적합니다.

So, if you have an empty object literal, it is represented by just Object(). 예를 들어, {} (빈 객체)를 생성하면, 내부적으로 Object() 형태로 표현됩니다.

If you have a literal with a property x, then we transition from the empty literal type to the next type, 객체에 x 속성을 추가하면, 기존 타입에서 새로운 타입으로 전환(Transition) 이 발생합니다.

That’s a literal with an x property. 즉, { x: 10 } 같은 객체는 새로운 내부 구조(Shape) 를 가지게 됩니다.

And then if you have more properties, we transition over to more types of objects, 추가 속성이 더해지면, 객체의 내부 타입이 계속 변경(Transition) 됩니다.

So that’s an internal representation since you don’t have to specify a class or anything in JavaScript, JavaScript에서는 클래스를 미리 정의하지 않아도 객체를 동적으로 변경할 수 있습니다.

You can just modify object types as you want. 즉, 실행 중에 자유롭게 속성을 추가/삭제 할 수 있습니다.

Internally, we keep track of a type of objects. 그러나 V8 엔진은 각 객체의 타입을 내부적으로 추적(Tracking) 합니다.

And because of these transitions, it actually makes a difference if your object has x defined first or y defined first, 그리고 속성 추가 순서에 따라 내부적으로 다른 타입으로 취급될 수 있습니다.

So just because two objects have the same properties, 따라서 동일한 속성을 가진 두 개의 객체라도

They’re not the same type internally. V8 내부에서는 다른 타입으로 간주될 수 있습니다.

자바스크립트 최적화 예제: 최적화된 어셈블리 코드 분석

Alright, so I’m running the load function a few times, 이제 load 함수를 여러 번 실행해 보겠습니다.

And I’m always running them with these objects here. 항상 같은 구조의 객체(Shape) 를 넘겨서 실행합니다.

They look similar, but they are not the same objects. 이 객체들은 겉보기에는 동일해 보이지만, 각각 다른 인스턴스 입니다.

The x and y values are obviously different. 객체의 x 및 y 속성 값은 서로 다릅니다.

But all these objects have the same shape. 그러나 내부적으로 같은 Shape(타입) 을 공유합니다.

So, if I’m running the function a lot, 이제 이 함수를 여러 번 실행 하면,

Eventually, the compiler says, 컴파일러는 실행 패턴을 분석한 후,

“Hey, this is a hot function, let’s optimise it.” “이 함수가 자주 실행되므로, 최적화하자!” 라고 판단합니다.

And this is what it is being optimised to. 그리고 최적화된 코드(Assembly Code) 는 다음과 같이 생성됩니다.

So this is assembly code. 이제 어셈블리 코드(Assembly Code) 를 살펴보겠습니다.

But I will explain to you what is happening here. 이 코드가 어떻게 동작하는지 설명해 드리겠습니다.

At the top, I left out a little bit of stuff, 상단에는 일부 불필요한 코드를 생략했습니다.

This is where we set up the stack when we enter the function. 이 부분은 함수가 실행될 때 스택을 설정하는 코드 입니다.

The important thing is here: 하지만 가장 중요한 부분은 다음 코드입니다.

This address corresponds to the type of the object that we fed the function with. 이 메모리 주소(Address) 는 함수에 전달된 객체의 타입 을 나타냅니다.

So, internally, this address represents an object that has an x and a y. 즉, x와 y 속성을 가진 객체의 타입 정보 입니다.

So this is optimised code that was generated after we have run the function a few times. 이 코드는 함수를 여러 번 실행한 후 생성된 최적화된 코드 입니다.

And it has memorised this type, 컴파일러는 해당 객체 타입을 기억(Memorise) 합니다.

And now when we run this function again, 이제 같은 타입의 객체 가 다시 전달되면,

We load this type, and then we do a comparison. V8 엔진은 타입을 로드(Load)한 후, 비교(Comparison) 를 수행합니다.

We are comparing our parameter where it has the same type as what we saved before. 즉, 새로운 객체가 이전에 기록한 타입과 일치하는지 검사합니다.

If the comparison is true, 비교 결과가 참(True) 이면,

We move over here where we now are getting the value of x. 바로 메모리에서 x 값을 가져옵니다.

So this is the address of the object plus 17, 예를 들어, object의 메모리 주소 + 17 바이트(offset) 에서 x 값을 읽어옵니다.

Which means take a memory offset of the object because we know at this position, it is the x value. 즉, 메모리에서 x 값의 위치를 미리 알고 있기 때문에,

So this short cut corresponds to the value for x. 빠르게 x 값을 가져올 수 있습니다.

객체 속성 접근의 최적화된 방식

And then there is one comparison saying, 그리고 이제 하나의 비교 연산(Comparison)이 실행됩니다.

“Is this the same?” “이 객체 타입이 동일한가?” 라고 확인한 후,

Use the value, done. 해당 값을 사용하고 종료하는 방식입니다.

This is the general idea. 이것이 자바스크립트 엔진의 최적화 원리입니다.

Store information or collect information by running, 즉, 실행하면서 정보를 수집하고,

Recompile, 재컴파일(Optimisation)하여,

Assuming we get the exact same type of inputs, 같은 타입의 입력이 계속될 것이라고 가정하는 방식입니다.

Like different values but similar types, 즉, 값은 달라도 타입이 동일한 경우 최적화가 유지됩니다.

And then the resulting code is really fast as long as you don’t change types. 따라서 객체의 타입을 바꾸지 않는 한, 실행 속도가 매우 빠르게 유지됩니다.

ES6의 최적화 사례: Computed Property Names

We recently implemented this speed-up for an ES6 feature. 우리는 최근 ES6(ECMAScript 2015)의 한 기능을 최적화했습니다.

In ES6, you have the option to define object literals with computed property names. ES6에서는 Computed Property Name(계산된 속성 이름) 을 지원합니다.

In ES5, ES5(이전 버전)에서는,

When you had a variable as a key, 속성 키(Key)에 변수를 사용할 경우,

You first had to create the object and then you could set that property. 먼저 객체를 생성한 후 속성을 추가하는 방식을 사용해야 했습니다.

So, if x is a variable and you want o[x], 즉, x 변수를 속성으로 사용하여 o[x]를 설정하려면,

You have to create the literal. 객체를 먼저 생성한 후,

Then assign the property. 속성을 추가해야 했습니다.

In ES6, you can do this in one step. 하지만 ES6에서는 한 단계로 처리할 수 있습니다.

Just use the brackets inside the object notation. 객체 리터럴 내에서 대괄호([])를 사용하면 됩니다.

We saw in benchmarks that this right-hand side is a lot slower than the ES5 equivalent. 그러나, 벤치마크 결과에 따르면, ES6 방식이 ES5보다 훨씬 느렸습니다.

You saw in the last talk the list of benchmarks, 지난 발표에서 보셨던 벤치마크 결과 리스트를 보면,

The yellow and green thing. 노란색과 초록색으로 표시된 부분이 있었습니다.

This one was red because it was so much slower than the ES5 counterpart. 그러나 이 기능(ES6 Computed Property Name)은 빨간색으로 표시될 정도로 ES5보다 성능이 낮았습니다.

But we applied the same principle. 그래서 우리는 앞서 설명한 최적화 원리를 적용했습니다.

A lot of times in this kind of code, 이러한 코드에서는,

The x is a symbol, 대부분 x가 심볼(Symbol) 로 사용됩니다.

And every function runs the same symbol, 그리고 일반적으로 같은 심볼을 반복적으로 사용합니다.

So we applied this principle here. 그래서 이 점을 활용하여 최적화했습니다.

We run the code a few times, 즉, 코드를 몇 번 실행하면서,

We memorise what x is, x의 값(타입 포함)을 기억(캐싱) 한 후,

And optimise to a fast path, 빠른 경로(Fast Path)로 최적화하였습니다.

Saying, 즉,

“If it is the same symbol we’ve seen all the time,” “만약 우리가 이전에 봤던 것과 같은 심볼(Symbol) 이라면,

Then this is the kind of object we are creating, 이 객체는 이 타입으로 취급된다” 라고 설정합니다.

Instead of making these expensive object transitions when we are creating this every time. 그 결과, 객체 타입 전환 비용(Object Transition Cost)이 크게 줄어들었습니다.

So by applying these optimisation principles, 이러한 최적화 기법을 적용한 덕분에,

We’ve got a ten-times speed-up on that benchmark, 벤치마크 결과가 10배 이상 개선되었습니다.

And the yellow-green benchmark list is on par with the ES5 equivalent. 이제 벤치마크에서 ES6 코드의 성능이 ES5와 동등한 수준으로 올라갔습니다.

You can use this ES6 feature without having to worry that it would slow down your performance if that is really critical to you.

이제 이 ES6 기능을 성능 저하에 대한 걱정 없이 사용할 수 있습니다. 만약 성능이 정말 중요한 요소라면 안심하고 사용할 수 있습니다.

So far, the high-level overview, you can’t put too much into 25 minutes.

지금까지 전체적인 개요를 다루었는데, 25분 안에 모든 내용을 다룰 수는 없었습니다.

I hope I was able to give you some idea of what is going on.

이 강연을 통해 여러분이 JavaScript 엔진 내부에서 어떤 일이 벌어지는지 조금이라도 이해할 수 있었으면 합니다.

If you want to dig deeper into that, of course, you can try it out yourself and make your own experiments and see what is going on.

만약 더 깊이 파고들고 싶다면, 직접 실험해 보면서 어떻게 작동하는지 확인할 수 있습니다.

All the engines are open source, or all the engines I mentioned are open source.

제가 언급한 모든 JavaScript 엔진들은 오픈 소스입니다.

You can get the source code, look at that, of course.

여러분은 이 엔진들의 소스 코드를 직접 확인해볼 수 있습니다.

But you can play around with it.

그리고 직접 실행해 보면서 테스트할 수도 있습니다.

You probably have Node installed anyways, so use Node or Chrome and pass in a few flags.

아마도 Node.js는 이미 설치되어 있을 테니, Node나 Chrome을 사용하여 몇 가지 플래그를 전달해 보세요.

If you pass in --print-opt-code, you will see the optimized code that I have just shown you.

예를 들어 --print-opt-code 옵션을 사용하면, 제가 앞서 보여드린 최적화된 코드가 출력됩니다.

So, because of how JavaScript is dynamically typed, we have to use JIT compilation to get any kind of speed.

JavaScript는 동적 타입 언어이기 때문에, 속도를 높이기 위해 JIT(Just-In-Time) 컴파일을 사용할 수밖에 없습니다.

Because of how the optimizing compilers under JIT work, your JavaScript code, if it’s statically typed, then that’s the best thing you can do for the compilers.

JIT의 최적화 컴파일러가 작동하는 방식을 고려할 때, 여러분의 JavaScript 코드가 정적 타입에 가깝다면, 이는 컴파일러가 최적화하기에 가장 좋은 조건이 됩니다.

Thank you. [Cheering].

감사합니다. [환호]

사회자: Thank you very much to Franziska for the excellent introduction to how the engine works in JavaScript - very interesting topic.

사회자: JavaScript 엔진의 작동 원리를 훌륭하게 설명해 주신 프란치스카에게 감사드립니다. 정말 흥미로운 주제였네요.

I think when we work practically with JavaScript, we don’t know what is going on on the system level, we don’t know how our code is being compiled.

실제 JavaScript를 개발할 때, 우리는 시스템 레벨에서 무슨 일이 벌어지는지 잘 모르는 경우가 많고, 코드가 어떻게 컴파일되는지도 알기 어렵습니다.

We’re going to start again in just a couple of minutes with our next talk,

잠시 후 다음 발표를 시작할 예정입니다.

and, if anyone is here who is curious about what is going on in the other track, we have Ben Vinegar talking about source maps.

만약 다른 세션에서 어떤 내용이 진행되는지 궁금하다면, 벤 비니거(Ben Vinegar)가 소스맵(Source Maps)에 대해 이야기하는 세션이 진행 중입니다.

GraphQL has put flyers out on the table. They have a discount code.

GraphQL에서 홍보 자료를 배포했으며, 할인 코드도 제공하고 있습니다.

It is another conference that’s going to be taking place just across the river on the 21st of this month.

이번 달 21일, 강 건너편에서 또 다른 컨퍼런스가 열릴 예정입니다.

We will be starting in just a couple of minutes.

몇 분 후에 다시 시작하겠습니다.