Seokho’s blog

디버깅 노트 — pdf.js 폰트 버그로 Chromium 이슈 등록하기

2025-08-27T00:00:00+00:00

최근에 회사 프론트엔드 제품에서 발견한 이슈를 chromium 이슈 트레커 crbug에 제보했다. 이 블로그 포스트에서는 브라우저 이슈라고 파악한 과정과 최소한의 재현 코드로 리포트한 방법을 간략히 공유하려고 한다.

issue: https://issues.chromium.org/u/1/issues/439716343

얼마 전 CS팀에서 일부 사용자들이 Android 기기에서 PDF를 볼 때 텍스트가 깨진다고 공유했다.

ANDROID:

iOS 시뮬레이터:

PDF의 전체 내용은 공유할 수 없다.

우리 제품은 pdf.js를 사용해서 PDF 바이너리를 렌더링하는데, 꽤 오래된 버전을 사용하고 있다. 처음에는 버전 관련 문제라 생각했다. 설령 버전 문제가 맞다고 한다고 하더라도, 왜 Android에서만 문제가 나타날까?

안드로이드에서만 발생하는 현상으로 이 문제는 브라우저 관련 이슈라고 의심하기 시작했다. 하지만 이를 확인하려면 여러 레이어를 거쳐 어느 레이어에서 문제가 발생하는지 파악해야 한다. 지난 몇 년간 브라우저 프로젝트에 기여한 경험상, 최소한의 재현 코드(즉, 버그를 재현하는 기본 코드)가 있으면 조사하고 수정할 컴포넌트를 찾는 데 상당히 도움이 된다.

디버깅을 시작할 때, 어떤 폰트가 문제를 일으키는지 파악해야 했다.

pdf.js의 텍스트 렌더링 코드에 로깅을 추가했다.

+
      if (!fontObj) {
        throw new Error(`Can't find font for ${fontRefName}`);
      }
@@ -1321,6 +1323,8 @@ var CanvasGraphics = (function CanvasGraphicsClosure() {

      var rule = italic + ' ' + bold + ' ' + browserFontSize + 'px ' + typeface;
      this.ctx.font = rule;
+
+      console.log('font changed: ', rule);
    },
    setTextRenderingMode: function CanvasGraphics_setTextRenderingMode(mode) {
      this.current.textRenderingMode = mode;
@@ -1483,6 +1487,7 @@ var CanvasGraphics = (function CanvasGraphicsClosure() {
      ctx.lineWidth = lineWidth;

      var x = 0, i;
+      console.log('drawing ',glyphs.map(g=>g.fontChar).join(''));
      for (i = 0; i < glyphsLength; ++i) {
        var glyph = glyphs[i];

출력 예시:

canvas.js:1327 font changed:  normal normal 16px "g_d0_f2", sans-serif
canvas.js:1490 drawing  Hence,recordingandcompilingatrace
canvas.js:1327 font changed:  normal normal 16px "g_d0_f10", sans-serif
canvas.js:1490 drawing  speculates
canvas.js:1327 font changed:  normal normal 16px "g_d0_f2", sans-serif
canvas.js:1490 drawing  thatthepathand

pdfjs가 여러 폰트 패밀리를 처리하고 있다는 것을 발견했다. Canvas API의 context.font property를 사용한다. CSS 규칙과 동일하다.

다음으로, 폰트 파일이 어디서 로드되는지 추적했다.

보다시피, 폰트 파일은 document.fonts property를 통해 로드되며, 이를 통해 일반적인 방식으로 폰트 패밀리를 사용할 수 있다.

이제 pdfjs가 폰트를 어떻게 처리하는지 알게 되었다.

그 다음 pdfjs가 PDF 바이너리에서 폰트를 파싱하고 로드하는 방식을 살펴봤다.

PDF 바이너리 읽기
CID fonts 파싱
- CFF Parser: https://github.com/mozilla/pdf.js/blob/master/src/core/cff_parser.js
- 결과는 메타데이터와 Uint8Array 폰트 데이터다.
- 그 다음 앞서 언급한 대로 FontFace를 생성하고 document.fonts에 추가한다
```
    addNativeFontFace(nativeFontFace) {
      this.nativeFontFaces.add(nativeFontFace);
      this._document.fonts.add(nativeFontFace);
    }
```
- 참고: https://github.com/mozilla/pdf.js/blob/dd560ee453c8189a9cb1ee1dea164ca1702ad020/src/display/font_loader.js#L48
- https://developer.mozilla.org/en-US/docs/Web/API/Document/fonts

파싱 과정을 아래 코드를 집어넣어 마지막에 폰트 blob을 다운로드하도록 했다.

function detectFontType(u8) {
  const h0 = u8[0], h1 = u8[1], h2 = u8[2], h3 = u8[3];
  const sig = String.fromCharCode(h0, h1, h2, h3);
  if (sig === 'wOFF') return { mime: 'font/woff',  ext: '.woff'  };
  if (sig === 'wOF2') return { mime: 'font/woff2', ext: '.woff2' };
  if (sig === 'OTTO') return { mime: 'font/otf',   ext: '.otf'   }; // OpenType/CFF
  if (h0 === 0x00 && h1 === 0x01 && h2 === 0x00 && h3 === 0x00) {
    return { mime: 'font/ttf', ext: '.ttf' }; // TrueType/OpenType
  }

  return { mime: 'application/octet-stream', ext: '.bin' };
}


function downloadBlob(u8, filename = 'font') {
  const { mime, ext } = detectFontType(u8);
  const blob = new Blob([u8], { type: mime });
  const url = URL.createObjectURL(blob);
  const a = Object.assign(document.createElement('a'), {
    href: url, download: filename.endsWith(ext) ? filename : filename + ext
  });
  document.body.appendChild(a);
  a.click();
  a.remove();
  URL.revokeObjectURL(url);
} 

if(nativeFontFace.family === 'g_d1_f5') {
   downloadBlob(this.data);
 }

이제 추출된 .otf 폰트 파일을 얻었다.

이 .otf 파일들을 사용해서 최소한의 재현 코드를 만들었다:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Canvas Font Test</title>
    <style>
        body {
            margin: 20px;
            font-family: system-ui, -apple-system, sans-serif;
        }
        .canvas-container {
            margin-bottom: 30px;
        }
        canvas {
            border: 1px solid #ccc;
            margin-top: 10px;
        }
        h2 {
            margin: 10px 0;
            color: #333;
        }
    </style>
</head>
<body>
    <h1>Canvas Font Test</h1>

    <div class="canvas-container">
        <h2>g_d1_f16.otf</h2>
        <canvas id="canvas_f16" width="800" height="200"></canvas>
    </div>

    <div class="canvas-container">
        <h2>g_d1_f5.otf</h2>
        <canvas id="canvas_f5" width="800" height="200"></canvas>
    </div>

    <div class="canvas-container">
        <h2>g_d1_f6.otf</h2>
        <canvas id="canvas_f6" width="800" height="200"></canvas>
    </div>

    <div class="canvas-container">
        <h2>g_d1_f7.otf</h2>
        <canvas id="canvas_f7" width="800" height="200"></canvas>
    </div>

    <script>
    (async () => {
        // Font configurations
        const fontConfigs = [
            { name: 'G_D1_F16', file: 'g_d1_f16.otf', canvasId: 'canvas_f16' },
            { name: 'G_D1_F5', file: 'g_d1_f5.otf', canvasId: 'canvas_f5' },
            { name: 'G_D1_F6', file: 'g_d1_f6.otf', canvasId: 'canvas_f6' },
            { name: 'G_D1_F7', file: 'g_d1_f7.otf', canvasId: 'canvas_f7' }
        ];

        // Load all fonts
        const fontPromises = fontConfigs.map(config => {
            const font = new FontFace(config.name, `url('./${config.file}')`);
            return font.load().then(loadedFont => {
                document.fonts.add(loadedFont);
                return { ...config, loadedFont };
            }).catch(err => {
                console.error(`Failed to load font ${config.file}:`, err);
                return { ...config, error: err };
            });
        });

        const loadedFonts = await Promise.all(fontPromises);

        loadedFonts.forEach(config => {
            const canvas = document.getElementById(config.canvasId);
            const ctx = canvas.getContext('2d');

            ctx.fillStyle = 'white';
            ctx.fillRect(0, 0, canvas.width, canvas.height);

            if (config.error) {
                ctx.fillStyle = 'red';
                ctx.font = '16px sans-serif';
                ctx.fillText(`Error loading font: ${config.file}`, 10, 30);
                return;
            }

            ctx.fillStyle = 'black';
            
            ctx.font = '32px ' + config.name;
            ctx.fillText('The quick brown fox - ABC123', 20, 50);

            ctx.font = '32px ' + config.name;
            ctx.fillText('다람쥐 헌 쳇바퀴에 타고파', 20, 100);

            ctx.font = '32px ' + config.name;
            ctx.fillText('1234567890 !@#$%^&*()', 20, 150);

            ctx.font = '12px sans-serif';
            ctx.fillStyle = '#666';
            ctx.fillText(`Font: ${config.file}`, canvas.width - 200, canvas.height - 10);
        });
    })();
    </script>
</body>
</html>

이슈를 제보하고 chromium slack에 공유했다. 누군가가 이것이 폰트 컴포넌트나 SKIA와 관련이 있을 것 같다고 말해줬다.

그럼 다음은?

지금은 적절한 엔지니어가 이 이슈를 담당하기를 기다리고 있다. 만약 한동안 할당되지 않는다면, 아마도 이 이슈 자체를 직접 더 깊이 파볼 계획이다.

업데이트!

Dominik 이 이슈를 가져갔다! googlefonts/fontations 에 이슈를 올렸다고 한다. M131 부터 발생한거로 추정된다고 한다.

그리고 또 다른 업데이트!

업스트림에서 문제가 수정되었다. 새로운 폰트 엔진(아마 M131에서 활성화된 것으로 보인다)에서 나온 버그였다.

이번 수정은 캔버스 이슈뿐만 아니라 웹 플랫폼에서의 특정 폰트 렌더링 문제도 함께 해결한다는 점에서 의미가 크다.

문제가 있었던 PDF에서 이슈가 해결된 것을 확인했고, 10월 말에 릴리즈되는 M142에 포함되어 배포될 예정이다.

V8 기여 영역을 새로운 top tier 컴파일러 Turbolev 로 확장하기

2025-07-15T00:00:00+00:00

저는 최근들어 V8 기여 범위를 JS 를 구현하는 영역에서 더 낮은 레이어의 컴파일러 파이프라인으로 확장했습니다.

이 파이프라인은 바이트코드를 받아 기계어 코드를 생성하거나, 다음 컴파일러를 위한 새로운 그래프를 생성하는 역할을 합니다. 이 파이프 라인은 각각 Maglev와 Turbolev라고 불립니다.

이 글에서는 제가 어떻게 기여 영역을 확장했고, Turbolev 프로젝트에 어떤 기여를 했는지 설명할 것 입니다.

Backgrounds

V8과 JIT

V8은 크롬, NodeJS, Deno 등 많은 곳에서 사용되는 자바스크립트 엔진입니다. V8은 multi-tiering JIT 컴파일러를 가지고 있습니다. Just-in-time, 즉 JIT 컴파일은 프로그램 실행 전이 아닌 실행 중에 코드를 실시간으로 컴파일하는 방식입니다. [FYI: Wikipedia]

예를 들어, 아래 코드는 바이트코드로 컴파일 되어 바이트 코드가 가상 머신에서 실행됩니다. 다시 말해 실제 기계어가 아니라는 뜻 입니다.

Code:

function add(a, b) {
  return a + b;
}

add(1, 2);

Bytecode:

devsdk@dave ~/workspace/chromium/v8/v8 % ./out/arm64.release/d8 ~/workspace/chromium/playground/add.js --print-bytecode
[generated bytecode for function:  (0x2f3e0005d7cd <SharedFunctionInfo>)]
Bytecode length: 28
Parameter count 1
Register count 4
Frame size 32
         0xaef00100084 @    0 : 13 00             LdaConstant [0]
         0xaef00100086 @    2 : cf                Star1
         0xaef00100087 @    3 : 1b fe f7          Mov <closure>, r2
         0xaef0010008a @    6 : 6d 6f 01 f8 02    CallRuntime [DeclareGlobals], r1-r2
         0xaef0010008f @   11 : 23 01 00          LdaGlobal [1], [0]
         0xaef00100092 @   14 : cf                Star1
         0xaef00100093 @   15 : 0d 01             LdaSmi [1]
         0xaef00100095 @   17 : ce                Star2
         0xaef00100096 @   18 : 0d 02             LdaSmi [2]
         0xaef00100098 @   20 : cd                Star3
         0xaef00100099 @   21 : 6b f8 f7 f6 02    CallUndefinedReceiver2 r1, r2, r3, [2]
         0xaef0010009e @   26 : d0                Star0
         0xaef0010009f @   27 : b5                Return
Constant pool (size = 2)
0xaef0010004d: [TrustedFixedArray]
 - map: 0x2f3e00000605 <Map(TRUSTED_FIXED_ARRAY_TYPE)>
 - length: 2
           0: 0x2f3e0005d81d <FixedArray[2]>
           1: 0x2f3e00003e8d <String[3]: #add>
Handler Table (size = 0)
Source Position Table (size = 0)
[generated bytecode for function: add (0x2f3e0005d82d <SharedFunctionInfo add>)]
Bytecode length: 6
Parameter count 3
Register count 0
Frame size 0
         0xaef001000c8 @    0 : 0b 04             Ldar a1
         0xaef001000ca @    2 : 3f 03 00          Add a0, [0]
         0xaef001000cd @    5 : b5                Return
Constant pool (size = 0)
Handler Table (size = 0)
Source Position Table (size = 0)

위 바이트코드는 V8 가상 머신에서 기계어 코드처럼 동작합니다. 하지만 실제 기계어는 아닙니다.

함수가 충분히 “뜨거워”지면(자주 호출되면), JIT 컴파일러는 더 빠른 실행을 위해 이를 네이티브 기계어 코드로 최적화합니다.

function add(a, b) {
  return a + b;
}

%PrepareFunctionForOptimization(add);
add(1,2);
%OptimizeFunctionOnNextCall(add);
add(1,2);

add 함수는 다음과 같이 컴파일됩니다:

devsdk@dave ~/workspace/chromium/v8/v8 % ./out/arm64.release/d8 ~/workspace/chromium/playground/add.js  --allow-natives-syntax --turbofan --print-opt-code
--- Raw source ---
(a, b) {
  return a + b;
}


--- Optimized code ---
optimization_id = 0
source_position = 12
kind = TURBOFAN_JS
name = add
compiler = turbofan
address = 0x2be2001001d5

Instructions (size = 288)
0x140000020     0  a9bf7bfd       stp fp, lr, [sp, #-16]!
0x140000024     4  910003fd       mov fp, sp
0x140000028     8  a9be03ff       stp xzr, x0, [sp, #-32]!
0x14000002c     c  a9016fe1       stp x1, cp, [sp, #16]
0x140000030    10  f8520342       ldur x2, [x26, #-224]



  .-')   .-. .-')             _ (`-.    _ (`-.    ('-.  _ .-') _   
 ( OO ). \  ( OO )           ( (OO  )  ( (OO  ) _(  OO)( (  OO) )  
(_)---\_),--. ,--.  ,-.-')  _.`     \ _.`     \(,------.\     .'_  
/    _ | |  .'   /  |  |OO)(__...--''(__...--'' |  .---',`'--..._) 
\  :` `. |      /,  |  |  \ |  /  | | |  /  | | |  |    |  |  \  ' 
 '..`''.)|     ' _) |  |(_/ |  |_.' | |  |_.' |(|  '--. |  |   ' | 
.-._)   \|  .   \  ,|  |_.' |  .___.' |  .___.' |  .--' |  |   / : 
\       /|  |\   \(_|  |    |  |      |  |      |  `---.|  '--'  / 
 `-----' `--' '--'  `--'    `--'      `--'      `------'`-------' 
 
 /* 100줄이 넘는 기계어 코드가 있어 생략되었습니다 */

0x14000013c   11c  97fffffb       bl #-0x14 (addr 0x140000128)

Inlined functions (count = 0)

Deoptimization Input Data (deopt points = 4)
 index  bytecode-offset    pc
     0                2    NA
     1                2    NA
     2                2    NA
     3               -1    9c

Safepoints (stack slots = 6, entries = 2, byte size = 24)
0x1400000bc     9c  slots (sp->fp): 100000  deopt      3 trampoline:    11c
0x1400000e4     c4  slots (sp->fp): 000000

RelocInfo (size = 13)
0x1400000b4  full embedded object  (0x0263000446c5 <NativeContext[301]>)
0x1400000b8  near builtin entry
0x1400000e0  near builtin entry
0x140000110  constant pool (size 16)

--- End code ---

위에 있는 코드는 V8의 현재 최상위 티어 JIT 컴파일러인 Turbofan과 Turboshaft를 사용한 예시입니다.

Maglev와 Turbofan

앞서 언급했듯이 V8은 multi-tier JIT 컴파일러를 가지고 있습니다. Maglev는 중간 티어 JIT 컴파일러입니다. Turbofan과 Turboshaft는 높은 수준의 최적화된 코드를 생성하지만 컴파일하는 데 시간이 더 오래 걸립니다.

Compiler	Compile Speed	Optimization Level	Structure
Maglev	빠름	낮은 최적화	단순
Turbofan	느림	높은 최적화	복잡

V8의 tiering manager는 결정 로직에 따라 주어진 함수에 대해 티어를 적용합니다.

Turbolev

이름은 maglev + turboshaft에서 유래했습니다. 이 프로젝트는 Maglev의 IR(중간 표현)을 사용하여 기존의 Turbofan 컴파일러 프론트엔드를 대체하는 것을 목표로 하고 있습니다.

이전의 최상위 티어 JIT 컴파일러는 프론트엔드로 Turbofan을, 백엔드로 Turboshaft를 사용했습니다. Turbofan은 기존의 일반적인 CFG(Control Flow Graph) 기반 접근 방식이 아닌 Sea of Nodes를 최적화에 사용했습니다. 이는 이론적으로는 강력하지만, 복잡성과 유지보수성 측면에서 몇 가지 실용적인 단점이 있었습니다.

더 자세한 배경과 프로젝트의 시작에 대해 읽어보려면: Darius의 Land ahoy: leaving the Sea of Nodes · V8 를 읽어보세요. :)

저는 어떻게 이 프로젝트에 참여하게 되었을까요?

저는 몇 년 동안 V8 프로젝트의 JS 기능 영역에 기여해왔습니다. 하지만 메모리 관리와 JIT 컴파일러는 여전히 ‘블랙박스’처럼 느껴졌습니다. 외부 기여자로서, 새로운 ECMAScript 기능을 구현할 기회를 찾기가 점점 더 어려워지기도 했고 더 많은 영역에 기여하고 싶어서 블랙박스 내부를 들여다보기 위해 기여 영역을 확장하기로 결정했습니다.

과거 Float16Array CL JIT 부분을 리뷰해 줬던 적이 있는 Darius가 기억 났고, 최근에 v8.dev에 turbolev에 대한 글을 게시한 것을 봤습니다. 저는 제가 도울 일이 있는지 알아보기 위해 이메일을 보냈습니다.

Hi Darius,

I’ve noticed that it’s getting a bit tough to find contribution opportunities related to ECMAScript features as an external contributor. So I was wondering—are there any areas in the compiler side (like Turboshaft or Maglev), or GC/memory stuff, where I could possibly help out?

I’d love to learn more and hopefully get involved in a broader range of work in V8.

–

Regards,

Seokho

Darius 는 친절하게 Turbolev 프로젝트를 제안해줬습니다. 친절한 가이드에 따라 Turbolev 프로젝트에 참여하기로 마음을 먹었고 가장 온보딩하기 수월한 구현을 찾아보려 했습니다.

그렇게 첫번째 기여 목표를 찾아 나섰고, 찾은것은 Math.atan2 였는습니다. 이 함수는 비슷한 IEEE754 Binary 연산을 처리하는 Math.pow 기존 구현 경로가 있었기 때문입니다.

저는 CL 초안을 만들어 Darius, Marja, Victor, Leszek에게 질문이 담긴 이메일을 보냈고, 답변을 통해 친절한 설명 및 성능 측정 도구인 Pinpoint 관련 도움등을 받을 수 있었습니다.

기여 내용

Math.atan2 최적화를 시작으로 약 4개의 CL에 기여했습니다.

제가 최적화한 내용은 다음과 같습니다:

Math.atan2
Math.sqrt
`Array.prototype.at

… 및 리팩토링.

그중 하나를 소개합니다 - Implement Math.sqrt turbolev Math.sqrt 함수를 mid, top tier JIT 컴파일러가 지원할 수 있도록 개선했습니다.

Pinpoint에 따르면 성능이 61% 향상되었습니다.

Victor는 코드리뷰 과정에서 Amazing이라는 표현을 쓸 정도였습니다 ㅎㅎ.

이 최적화 과정을 풀어서 설명해보자면:

Floa64Sqrt maglev IR 노드를 추가했습니다.

maglev-ir.h

class Float64Sqrt : public FixedInputValueNodeT<1, Float64Sqrt> {
  using Base = FixedInputValueNodeT<1, Float64Sqrt>;

 public:
  explicit Float64Sqrt(uint64_t bitfield) : Base(bitfield) {}

  static constexpr OpProperties kProperties = OpProperties::HoleyFloat64();
  static constexpr
      typename Base::InputTypes kInputTypes{ValueRepresentation::kHoleyFloat64};

  Input& input() { return Node::input(0); }

  void SetValueLocationConstraints();
  void GenerateCode(MaglevAssembler*, const ProcessingState&);
  void PrintParams(std::ostream&) const;
};

그리고 maglev 그래프 빌더에 MathSqrt를 등록했습니다.

maglev-graph-builder.h

...
  V(MathRound)                                 \
  V(MathSqrt)                                  \
  V(MathClz32)                                 \
  V(SetPrototypeHas)                           \
...

이 매크로는 리듀서 함수를 선언합니다. C++ 컴파일러가 해당 함수의 구현부가 없는 것을 알려줍니다.

maglev-graph-builder.cc

MaybeReduceResult MaglevGraphBuilder::TryReduceMathSqrt(
    compiler::JSFunctionRef target, CallArguments& args) {
  if (args.count() < 1) {
    return GetRootConstant(RootIndex::kNanValue);
  }

  if (!CanSpeculateCall()) {
    ValueRepresentation rep = args[0]->properties().value_representation();
    if (rep == ValueRepresentation::kTagged) return {};
  }

  ValueNode* value =
      GetFloat64ForToNumber(args[0], NodeType::kNumber,
                            TaggedToFloat64ConversionType::kNumberOrUndefined);

  return AddNewNode<Float64Sqrt>({value});
}

이 리듀서는 Math.sqrt 같은 고수준 연산을 더 최적화된 저수준 IR 노드인 Float64Sqrt로 변환하는 역할을 합니다. 이 노드는 최상위 티어 JIT인 “turbolev”와 중간 티어 JIT인 “maglev”에서 사용될 것입니다.

Mid Tier Maglev - arm64:

maglev-ir-arm64.cc

void Float64Sqrt::SetValueLocationConstraints() {
  UseRegister(input());
  DefineSameAsFirst(this);
}
void Float64Sqrt::GenerateCode(MaglevAssembler* masm,
                               const ProcessingState& state) {
  DoubleRegister value = ToDoubleRegister(input());
  DoubleRegister result_register = ToDoubleRegister(result());
  __ fsqrt(result_register, value);
}

JIT 컴파일할 때, Float64Sqrt 노드는 arm64 아키텍처용 기계어 코드인 fsqrt로 컴파일 합니다. 비슷하게 x64에서는 SSE 명령어인 sqrtsd를 컴파일 할 것 입니다.

For Top-Tier Turbolev 컴파일용:

Float64Sqrt 노드는 turbolev-graph-builder에 의해 소비됩니다.

turbolev-graph-builder.cc

  maglev::ProcessResult Process(maglev::Float64Sqrt* node,
                                const maglev::ProcessingState& state) {
    SetMap(node, __ Float64Sqrt(Map(node->input())));
    return maglev::ProcessResult::kContinue;
  }

이 코드는 Maglev의 Float64Sqrt 노드를 입력으로 사용하여 Float64Sqrt Turboshaft 그래프 노드를 생성합니다. 여기부터 Turboshaft의 강력한 CFG 기반 백엔드가 Loop Unrolling, Store Elimination, Register Allocation과 같은 추가적인 최적화를 수행하여 더 높은 최적화를 진행합니다.

따라서, Math.sqrt가 hot and stable 상태가 되면, tiering manager는 Turbolev 컴파일을 트리거 합니다. (이 노드는 동일한 기계어 코드를 생성할 것 입니다. 하지만 Turboshaft가 이제 주변의 모든 코드에 강력한 최적화를 적용해 높은 최적화를 이룰 것 입니다.)

Concluding

위에서 언급한 과정을 통해 저는 V8의 Maglev 및 Turbolev 영역에 훨씬 더 익숙해지고, 블랙 박스를 많이 들여다 봤습니다. 하지만 아직 구현되지 않은 함수도 많고, 기여할 수 있는 기회가 많이 보입니다. 앞으로도 계속 기여하여 더 많은 시야를 얻을 수 있을 것 이라고 기대하고 있습니다. 어느날 이 코드베이스가 완전히 익숙해지면 WASM이나 메모리 등 다른 영역으로 또 한번 나아갈 생각입니다.

코드 리뷰를 해주고 좋은 가이드를 해준 동료 Darius, Marja, Victor, Leszek에게 감사 인사 드립니다. :).

V8 커미터가 되었습니다

2025-05-10T00:00:00+00:00

오늘 아침, V8 커미터가 되었습니다.

지난 2년간 남는 시간 대부분을 V8에 기여하는데 사용했습니다.

그동안 기여한 주요 내용은 다음과 같습니다.

주요 기능인 Float16Array 구현
- V8에 Float16 관련 기능 추가한 첫번째 이야기
- Float16Array Turbofan Pipeline 개발기 — Weekly Sync with V8 Leader
최적화를 통한 일부 연산 성능 향상
- V8의 Math.hypot 최적화 하기 - 반복의 숨은 비용
스팩과 다르게 동작하는 잘못된 동작 수정(7년간 방치된 버그 해결)

누군가한테 “V8 커미터가 되겠다”고 말했던 것 같은데 이제 그 목표를 이룬 것 같아 감개무량합니다.

저를 포함하여 전 세계에 75명 밖에 없다는 사실이 좀 놀랍기도 하구요.

이 프로젝트를 통해 정말 많은 것을 배웠고, 멋진 사람들도 많이 만났습니다.

작은 기여들이 세상을 조금 더 나아지게, 더 안전하고 더 빠르게 만드는 데 보탬이 되기를 바랍니다.

앞으로도 커미터로서 계속 최선을 다하겠습니다.

기여 목록 보기

Float16Array Turbofan Pipeline 개발기 — Weekly Sync with V8 Leader

2025-02-21T23:00:00+00:00

Introduction

이 글에서는 V8의 외부 컨트리뷰터로서 Float16Array를 구현한 이야기를 공유하면서 TurboFan과 Turboshaft의 최종 JIT 최적화에 초점을 맞춥니다. 몇 달에 걸쳐 저는 Google 엔지니어 Shu-Yu Guo와 매주 동기화를 진행하며 플랫폼별 과제를 해결하여 상당한 성능 향상을 달성했습니다.

Float16Array

Float16Array는 Uint32Array 혹은 Float32Array와 같은 타입 배열입니다. 16비트 부동 소수점 숫자(float16, 반정밀도)로 작동합니다. 특정 사용 사례에 적합한 정밀도를 유지하면서 Float32Array 및 Float64Array에 비해 부동 소수점 데이터를 처리하는 메모리 효율적인 방법을 제공합니다.

Float16Array는 웹 및 JavaScript 기반 애플리케이션에서 성능과 메모리 사용량을 최적화하는 데 사용할 수 있으며, 특히 WebGPU, WebGL 기반 애플리케이션과 같이 빠른 숫자 연산이 필요한 분야에서 유용하게 사용할 수 있습니다.

What is V8 and TUrBoFan ?

본격적으로 시작하기 전에 Turbofan, Turboshaft, 그리고 제가 기여하는 V8에 대해 간략히 소개하겠습니다.

What is V8?

V8은 JavaScript 코드를 실행하기 위한 자바스크립트 엔진입니다. V8에는 자바스크립트와 WASM을 실행하고 최적화하기 위한 대규모 파이프라인이 있으며, Chromium(Chrome, Edge, Whale 등의 기반), Node.js, Deno 등을 구성합니다.

V8 (JavaScript engine) - Wikipedia

What is the TurboFan?

아시다시피 JS는 인터프리터 위에서 실행되지만, 일반적으로 네이티브 언어(C, C++ 등)보다 느립니다.

Turbofan은 이러한 성능 격차를 좁히기 위한 최적화 도구입니다.

이 포스트에서는 모든 세부사항을 다루지 않을 겁니다. 기회가 된다면 따로 글을 작성하겠습니다. 위 그림을 보면, 입력으로 ByteCodeGraph(V8 자바스크립트 바이트코드에서 빌드된 그래프)가 있고, 출력은 타깃 머신별 코드를 생성해냅니다. 함수나 연산이 충분히 자주 호출되어 뜨거운 상태(자주 호출되는 상태)가 되면 파이프라인이 실행되어 최적화가 이뤄지고, 결국 머신 코드로 동작하게 됩니다.

Turboshaft 는 또 다른 제어 흐름 그래프 중간 표현(CFG-IR)으로, Turbofan과 머신 실행 코드 사이에 위치합니다. Turboshaft의 최종 결과는 실행 가능한 머신 코드가 됩니다.

JIT란?

JIT(Just-In-Time)는 컴퓨팅에서 성능을 최적화하기 위해 사용되는 기술로, 실행하기 전이 아닌, 실행 시점 직전에 코드를 컴파일합니다. 이~ 방식은 실행되는 환경에 맞춰 코드를 최적화할 수 있으므로, 프로그램이 더 빠르게 동작하도록 돕습니다.

Just-in-time compilation - Wikipedia

Histories

From Beginning

저는 여가시간에 취미로 기여하는 개인 기여자 입니다.

2024년 3월 스팩에 정의된 Float16Array, Math.f16round, 그리고 관련 DataView를 구현 했습니다. 코드 리뷰는 2023년 12월에 시작되었습니다. 70개의 패치셋과 80개 이상의 파일이 변경되고, 코드 리뷰 전 구현 단계에서 2023년 3~4분기의 개인 시간이 많이 투입될 정도로 거대한 프로젝트였습니다.(관련 포스트)

리뷰어들과 저는 변경이 너무 방대하니, 기능 구현과 Turbofan JIT 지원 부분을 분리하기로 합의했습니다. 결국 여기에서 항상 deoptimization하도록 하는 코드를 추가했는데, 이 코드는 이후 Darius에 의해 개선되었습니다.

2024년 3월 말, 저는 Float16Array가 릴리즈 준비가 되었다고 판단했고, Shu에게 “Intent to Ship 프로세스를 진행할 준비가 되었느냐”는 메일을 보냈습니다. 그에 대한 답변은, 제가 위에서 언급한 Deoptimization 코드를 해결해야 한다는 것이었습니다. 적어도 fp16.h 안에 있는 소프트웨어 에뮬레이션 함수를 호출해야 한다고 했습니다. 즉, Turbofan 파이프라인 이후에 런타임 함수를 호출하는 형태가 필요했습니다.

지금은 그 말이 어떤 의미인지 알지만, 당시에는 “Turbofan이 뭔지, 어떻게 동작하는지”를 알아내야 하는 상황이었습니다. 그래서 일요일 대부분의 시간을 투자해가며 Turbofan 코드를 읽고 작성하기 시작했고, ‘float16 값을 변환’하는 빌트인 함수를 호출하는 파이프라인 단계를 구현했습니다.

그러나… 2분기, 3분기에 개인 사정(시험 준비)으로 우선순위를 바꿔야 했습니다.

시간은 정말 빠르게 지나가 4분기가 되었습니다. 종종 Float16Array 관련 메일이나 작업이 오긴 했지만, 더딘 진행과 기회를 놓칠 수 있다는 불안감이 있었습니다.

4분기 초, Shu로부터 메일이 왔습니다. Float16Array는 이제 개발이 가능하고, x64와 ARM에서 float16 <-> float64 변환 작업을 Ilya가 진행 중이라는 내용이었습니다.

그래서 “내장 함수를 호출하자”라는 저의 기존 계획을 바꿔 다음과 같은 새로운 계획을 세웠습니다:

머신에서 float16 변환을 지원하는 패치가 준비될 때까지 대기
변환 코드를 검토해 범위를 파악
js-native-context-specialization의 “Always Unoptimize” 코드를 제거
각 단계마다 Turbofan 노드를 연결해 Float16Array를 지원
Ilya가 구현한 노드나 파이프라인과 연결 (어느 단계가 최적인지 조사 필요)
float16을 지원하지 않는 머신을 위한 Fallback으로 (uint16을 사용하는) 런타임 함수를 호출하는 방안도 고려

시간은 흘러 11월이 되었고, 코드를 읽고 시간이 있을 때 위의 계획을 구현하려고 노력했습니다. 11월의 어느 날, 업스트림의 일부 변경 사항이 실험용 Float16Array 코드와 부분적으로 충돌하는 것을 발견했습니다. 위에서 언급한 것 처럼 충돌이 일어날 수 있다는 우려가 현실이 된 것 입니다. 그리고 이것이 중복 작업을 만들 수 있다고 생각했습니다. 어떻게 해야할 지 혼란스러웠고, 길을 잃은 것 같았습니다.

그래서, 구현 상태나 진행 상황, 그리고 막힌 부분을 더 자주 공유해야겠다고 결심했습니다. 11월 중순, 작은 멘토링이나 매니징 도움을 기대하며 “주간 싱크”를 요청하는 메일을 보냈습니다:

Hi syg,

And I think the turbofan and turboshaft code is much more complex than I thought… Is there any mentoring system or programme for this?

I may need to tighten the feedback loop for myself to release in this year. If you don’t mind, can I send some kind of weekly or some periodic update email that might include what I’m considering or what I’m stuck on?

Regard

Seokho

Hi syg,

Turbofan, Turboshaft 코드가 생각보다 훨씬 복잡한 것 같아요… 이에 대한 멘토링 시스템이나 프로그램이 있나요?
올해 안에 배포하려면 피드백 루프를 더 강화해야 할 것 같습니다. 괜찮다면 매주 또는 주기적으로 제가 고려하고 있는 사항이나 막혀 있는 사항을 포함한 업데이트 이메일을 보내도 될까요?

Regard

Seokho

이 메일을 보낼 때, 제 코드 이해 부족이나 역량을 드러내고 시간을 뺏는 게 아닐까 걱정도 됐고, 기회를 잃게 되지 않을까 두려움도 있었습니다.

정말 기쁘게도 다행히 그가 좋다고 답해줬습니다.

Progression:

이렇게 해서 주간 싱크를 본격적으로 시작하게 되었습니다.

First week - Sync the Context

첫 주에는, 위의 히스토리와 맥락을 정리해 Shu에게 보여주기 위한 준비를 했습니다. 그리고 임시 WIP CL을 열어 현재 진행 상황을 공유했습니다. 이메일 내용도 위와 같은 히스토리로 가득 습니다. 길을 찾기를 바라면서 메일을 보냈습니다.

이메일 내용 일부를 발췌하면 다음과 같습니다:

B. The plan:

Sooo, It seems machine support is now possible thanks to Ilya’s changes. I noticed the following in the Turboshaft graph builder:
UNARY_CASE(TruncateFloat64ToFloat16RawBits, TruncateFloat64ToFloat16RawBits).

One remaining task appears to be removing the force-deoptimize code in src/compiler/js-native-context-specialization.cc and adding a UNARY_CASE for ChangeFloat16ToFloat64.

Additionally, should we consider retaining software calculations for cases where machines do not support FP16 operations? If so, where would be the best place to handle this in Turbofan?

So… the question is whether my assumption about the remaining task is correct.

C. Next action plan:

당시 다음 단계에 무엇을 해야할지 불확실한 느낌이 들어 B. 계획 부분에 대해 동기화하기를 기대했습니다.

그리고 Shu는 정말 고맙게도 디테일한 계획을 제시해주었습니다. :)

계획 요약:

마이크로벤치마크 작성
float64->float16 저장(즉 Float16Array에 쓰기) 시의 Deoptimization 제거
필요하다면, 새로운 ‘truncation operator’ 추가
해당 새 오퍼레이터를 TruncateFloat64ToFloat16RawBits 오퍼레이터로 낮춤(lower) (즉 소프트웨어 에뮬레이션이 아닌 경로를 동작시키기)
지원 안 되는 환경에선 C 함수를 호출하여 truncation 처리(소프트웨어 에뮬레이션 경로)
float16->float64 (즉 Float16Array에서 값 읽기)도 같은 방식으로 반복
마이크로벤치마크 성능이 향상되었는지 확인

Second Week - Execute what we synced

둘째 주에는, 첫 주에 싱크 용으로 만들어뒀던 WIP CL을 버리고, 간단한 마이크로벤치마크 코드를 작성했습니다:

const ITERATION = 100000000

const array = new Float16Array(10000)

function store(i) {
  array[i % 10000] = 1.1 + 0.01 * (i % 10)
}

function load(i) {
  return array[i % 10000]
}

for(let i = 0; i< ITERATION; i+=1) { // heater
  store(i)
}

let sum  = 0;


for(let i = 0; i< ITERATION; i+=1) { // heater
  load(i)
}

console.log("N = ", ITERATION)

console.time('store');

for(let i = 0; i< ITERATION; i+=1) {
  store(i)
}

console.timeEnd('store');

console.time('load');

sum  = 0;
for(let i = 0; i< ITERATION; i+=1) {
  sum+= load(i)
}

console.timeEnd('load');

console.log("SUM = ", sum)

console.log("BYTE LENGTH: " ,array.BYTES_PER_ELEMENT)

(이 코드는 “항상 Deoptimization” 상태에서의 결과) 실행 시간:

N =  100000000
console.timeEnd: store, 2242.493000
console.timeEnd: load, 1853.342000

이번주에는 주로 소스 코드의 ‘store’ 경로를 확인하면서, float16 변환을 처리하기 위해 Turbofan 노드를 어떻게 생성할지를 살폈습니다. turbolizer 를 사용해 그래프도 확인하고, representation change phase를 디버깅했습니다.

하지만 제가 생성한 그래프 빌드/수정 방법이 맞는 건지 확신이 서지 않았습니다. (쓰지 말아야 할 코드를 억지로 넣은 느낌이었거든요)

위에서 말한 어색하다고 느낀 지점을 포함해 메일로 공유했습니다.

…

I found a code chunk of calling external reference functions but I need to figure out how to connect with our TruncateFloat64ToFloat16RawBits.

PLAN: 5.1: Investigate where I should call / process platform specific code to process TruncateFloat64ToFloat16RawBits node from your suggestion ‘machine_lowering’ code. (Maybe if there are some existing codes there will be great)

5.2: Write the code to call the software/hardware support code.

5.3: Find out how to separate Float32 in representation-change steps.

외부 참조 함수를 호출하는 코드 덩어리를 찾았지만 TruncateFloat64ToFloat16RawBits와 연결하는 방법을 알아내야 합니다.

PLAN: 5.1: 제안하신 ‘machine_lowering’ 코드에서 플랫폼별 코드를 어디에서 호출/처리하여 TruncateFloat64ToFloat16RawBits 노드를 처리해야 하는지 조사합니다. (기존 코드를 알 수 있다면 좋을 것 같습니다.)

5.2: 소프트웨어/하드웨어 지원 코드를 호출하는 코드를 작성합니다.

5.3: Float32를 representation-change 단계에서 분리하는 방법을 알아봅니다.

Third Week - Software Emulation Work!

세 번째 싱크는 2024년 12월 1일이었습니다. 마침 일요일이었고, 한국에서 첫눈이 내리던 날이었네요. (이걸 Shu에게 메일로 얘기했더라고요!)

모호한 이름 충돌도 일으키고 있는 불필요한 kJSFloat16TruncateWithBitcast관련 코드를 제거했습니다.
드디어 lower reducer에서 외부 레퍼런스 함수 호출 코드를 작성했습니다.

그런데 arm64에서 illegal hardware instruction 문제가 생겼습니다:

devsdk@Dave ~/workspace/chromium/v8/v8 % ./out/arm64.debug/d8 --js-float16array ~/workspace/chromium/playground/float16array_float16.js  
zsh: illegal hardware instruction  ./out/arm64.debug/d8 --js-float16array  

M1 arm64와 관련된 무언가라고 생각했습니다. (나중에 보니 무한 재귀 호출 문제가 원인이었어요)

외부 레퍼런스 함수(즉, C 함수를 직접 호출)로만 구현했을 때 하드웨어 연산이 아님에도 불구하고, 이미 200% 이상 속도가 빨라졌습니다!

devsdk@Dave ~/workspace/chromium/v8/v8 % ./out/x64.release/d8 --js-float16array ~/workspace/chromium/playground/float16array_float16.js  
N =  100000000  
console.timeEnd: store, 770.435000  
SUM =  0  
BYTE LENGTH:  2  

그리고, 다음 주 계획을 공유했죠:

그래프 빌딩 개선
load 경로 구현
몇 가지 이슈 조사…

Forth Week - Weird week

네 번째 주. 약간 이상하고 힘든 한 주였습니다. 모두가 기억하듯 대통령이 지난 수요일에 계엄령을 선포했다가 국회에서 중지시켰거든요…

그리고 Shu도 이메일에서 “뉴스에서 봤어요! 격동의 시기인 것 같은데, 이번 CL은 걱정하지 않아도 될 것 같습니다”라고 답을 보냈습니다. 🤣

개인적으로도 이번 주에는 시간이 넉넉하지 않아 작업량이 적었습니다.

그래도 load 경로를 구현하고, DoNumberToFloat16RawBits라는 함수를 구현했습니다.

다음 주 계획:

마이크로벤치마크 실행
제가 제거했던 kJSFloat16TruncateWithBitcast가 정말 필요 없는지 확인
“load”에 대한 머신 지원 코드 구현

Fifth Week - Hardware instruction works but another issue come

다섯 번째 싱크도 시간이 짧았습니다. 일본 여행 계획이 있었거든요. 여행 전까지, 하드웨어 지원 경로를 구현하고, 왜 ‘illegal instruction’ 이슈가 생겼는지 파악했습니다.

Email content:

Hi syg

I’m going on an away trip this weekend, so I’m trying to sync now.

And with hardware support (only for store yet):

devsdk@Dave ~/workspace/chromium/v8/v8 % ./out/arm64.release/d8 –js-float16array ~/workspace/chromium/playground/float16array_float16.js

N = 100000000

console.timeEnd: store, 133.083000

(It super fast)

I kept kJSFloat16TruncateWithBitcast to use instruction selection to fix illigal instruction issue that we mentioned in previous email on arm64.It was caused by by infinite call loop TrucateFloat64ToFloat16RawBits -> ReduceXXX -> TrucateFloat64…

The arm64 native support that kept kJSFloat16TruncateWithBitcast through ReduceIfReachableChange makes the x64 software path that implemented our reducers is broken. I’ll have a look at it after my trip.

안녕하세요. Syg!

이번 주말에 여행을 떠날 예정이라 지금 메일을 보냅니다.

그리고 하드웨어 지원(아직 스토어에만 해당)도 제공됩니다:

devsdk@Dave ~/workspace/chromium/v8/v8 % ./out/arm64.release/d8 –js-float16array ~/workspace/chromium/playground/float16array_float16.js

N = 100000000

console.timeEnd: store, 133.083000

(매우 빠릅니다)

이전 이메일에서 언급 한 illigal instruction 문제를 해결하기 위해 명령어 선택을 사용하기 위해 kJSFloat16TruncateWithBitcast를 유지했습니다.이 문제는 무한 호출 루프 TrucateFloat64ToFloat16RawBits -> ReduceXXX -> TrucateFloat64…로 인해 발생했습니다.

reduceIfReachableChange를 통해 kJSfloat16TruncateWithBitcast를 유지했던 arm64 네이티브 지원 덕분에 구현했던 Reducer의 x64 소프트웨어 경로가 깨졌습니다. 여행 후에 한번 살펴보겠습니다

그리고 일본 여행 관련 얘기도 좀 했어요. (이 사진을 찍었습니다!)

결국 software emulation load 경로도 구현했습니다.

이후, 전체 테스트를 돌려봤습니다.

그리고 마침내! 코드 정리를 조금 거친 뒤 리뷰를 받기 위한 CL을 준비했습니다.

최종 벤치마크 결과:

Without any optimization (original)
N =  100000000
console.timeEnd: store, 2242.493000
console.timeEnd: load, 1853.342000

Software calculation (calling the fp16.h):
N =  100000000
console.timeEnd: store, 379.250000
console.timeEnd: load, 606.833000

arm64 hardware operation:
N =  100000000
console.timeEnd: store, 128.042000
console.timeEnd: load, 603.542000

store의 경우 약 500% 이상, load는 약 300% 향상되었습니다!

Sixth Week - THE REVIEW PHASE

이제… 리뷰 단계입니다!

변경된 코드 중 핵심을 요약하면:

하드웨어 지원을 통해 머신 코드를 생성하기 위해 터보샤프트에서 파이프라인 단계로 정의된 float16-lowering-reducer.h를 만들었습니다. (추후 추가 작업으로 삭제되었습니다!) 그리고 float64를 float16으로 변경하기 위한 외부 참조 함수의 대상을 변경했습니다. 마지막으로 tc39/test262에 정의된 테스트코드에 다양한 edge case를 추가했습니다.

const edgeCases = [
  // an integer which rounds down under ties-to-even when cast to float16
  { input: 2049, expected: 2048 },
  // an integer which rounds up under ties-to-even when cast to float16
  { input: 2051, expected: 2052 },
  // smallest normal float16
  { input: 0.00006103515625, expected: 0.00006103515625 },
  // largest subnormal float16
  { input: 0.00006097555160522461, expected: 0.00006097555160522461 },
  // smallest float16
  { input: 5.960464477539063e-8, expected: 5.960464477539063e-8 },
  // largest double which rounds to 0 when cast to float16
  { input: 2.9802322387695312e-8, expected: 0 },
  // smallest double which does not round to 0 when cast to float16
  { input: 2.980232238769532e-8, expected: 5.960464477539063e-8 },
  // a double which rounds up to a subnormal under ties-to-even when cast to float16
  { input: 8.940696716308594e-8, expected: 1.1920928955078125e-7 },
  // a double which rounds down to a subnormal under ties-to-even when cast to float16
  { input: 1.4901161193847656e-7, expected: 1.1920928955078125e-7 },
  // the next double above the one on the previous line one
  { input: 1.490116119384766e-7, expected: 1.7881393432617188e-7 },
  // max finite float16
  { input: 65504, expected: 65504 },
  // largest double which does not round to infinity when cast to float16
  { input: 65519.99999999999, expected: 65504 },
  // lowest negative double which does not round to infinity when cast to float16
  { input: -65519.99999999999, expected: -65504 },
  // smallest double which rounds to a non-subnormal when cast to float16
  { input: 0.000061005353927612305, expected: 0.00006103515625 },
  // largest double which rounds to a subnormal when cast to float16
  { input: 0.0000610053539276123, expected: 0.00006097555160522461 },
  { input: NaN, expected: NaN },
  { input: Infinity, expected: Infinity },
  { input: -Infinity, expected: -Infinity },
  // smallest double which rounds to infinity when cast to float16
  { input: 65520, expected: Infinity },
  { input: -65520, expected: - Infinity },
];

Merged!

마침내 이 CL은 1월 27일에 머지되었습니다. 거의 반년 걸렸네요. 그래도 이제 Turbofan/Turboshaft 파이프라인에 꽤 익숙해졌습니다!

2024년 말쯤 끝나리라 예상했는데, 결국 1월 말이 되었습니다.

자바스크립트 API 프론트엔드에서부터 JIT 머신 코드 생성 백엔드까지, 정말 길고도 긴 여정이었습니다.

CL: chromium-review.googlesource.com/c/v8/v8/+/6043415

그리고 머지 후, 배포 준비를 하는 동안엔 미국 여행을 다녔습니다. Shu도 만났고요! 제가 미국 산호세에 체류 중일 때 이 CL이 머지되었어요.

V8 관련 기여, 그리고 제 커리어에 대한 이야기도 나눴습니다!

아마 이 내용은 따로 여행 관련 포스트로 따로 다룰 수도 있을 것 같네요.

어쨌든, 이제 이 기능을 릴리즈하기 위해 몇 가지 단계를 더 진행해야 합니다.

Prepare to ship

Blink-dev 구글 그룹에서 +3 LGTMs를 받아야 기능을 공개할 수 있습니다. (흔히 말하는 Intended to Ship, I2S)

Intent to Ship: Float16Array

드디어 2025년 2월 14일, +3LGTMs를 받았습니다!

And… Ship!

퍼저에서 발견된 버그를 일부 수정하고 쪽에 테스트 케이스를 추가했습니다. 일부 자동화에서 감지된 문제를 확인하기 위해 일주일을 기다렸습니다.

Shu가 Blink 쪽에서 퍼저가 감지하는 버그를 일부 수정했습니다. 일부 자동화에서 감지된 문제를 확인하기 위해 일주일을 기다린 끝에 마침내 기능 플래그를 기본으로 활성화하도록 전환했습니다! 제가 개발에 참여한 다른 기능이 세상에 공개되었습니다.

Chrome M135(2025년 3월 중순 출시)부터 새로운 Float16Array를 사용할 수 있습니다!

Feature Entry: https://chromestatus.com/feature/5164400693215232

V8의 Math.hypot 최적화 하기 - 반복의 숨은 비용

2024-03-18T21:00:00+00:00

Introduction

Chrome, NodeJS 등 자바스크립트를 실행하는 런타임의 엔진인 V8에 구현되어 있는 javascript 함수 Math.hypot 의 속도를 약 200% 향상했습니다.

Math.hypot 함수는 거리를 계산하는 데 많이 사용되는 함수입니다.

Hypotenuse = 빗변

이 글에서는 성능 저하를 해결하기 위해 생각했던 가설과 속도 저하가 발생했던 원인 및 해결책을 소개할 것입니다.

CL: https://chromium-review.googlesource.com/c/v8/v8/+/5329686

과정

이슈 발견

V8의 이슈를 목록을 보던 중 삼각형의 빗변 길이를 계산할 때 사용하는 Math.hypot 함수가 곱셈 연산자 등을 활용하여 구현 한 것 보다 수십 배 느리다는 이슈를 발견했습니다.

처음에 이 이슈를 발견했을 왜 다른 빌트인 함수(Math.pow, **)를 사용한 것 보다 Math.hypot을 쓴 게 특별히 더 느릴까? 라는 생각을 했습니다.

아래는 이슈에 같이 첨부된 퍼포먼스 측정을 위한 코드입니다.

const n = 100_000_000

const methods = {
	'*': (a, b) => Math.sqrt(a * a + b * b),
	'hypot': Math.hypot,
	'**': (a, b) => Math.sqrt(a ** 2 + b ** 2),
	'pow': (a, b) => Math.sqrt(Math.pow(a, 2) + Math.pow(b, 2)),
}

Object.entries(methods).forEach(([name, method]) => {
	let a = Math.random() * 3, b = Math.random() * 91.3, c = 1

	let s = performance.now()

	for(let i = 0; i < n; i++){
		c += method(a, b)
	}
	
	console.log(`${name} took ${performance.now() - s}`)
})

실제로 이 코드를 실행하면 보면 곱셈(*)을 사용한 것과 상당한 차이가 난다는 것을 알 수 있습니다.

Method	Runtime
*	103.292ms
hypot	1584.417ms
**	664.958ms
pow	666.458ms

Math.hypot 구현체 살펴보기

Math.hypot함수는 torque라는 언어로 작성되어 있고, src/builtins/math.tq 에 위치해 있습니다.

Torque는 타입스크립트와 비슷한 문법을 가진 V8내에서 사용하는 언어입니다.

// ES6 #sec-math.hypot
transitioning javascript builtin MathHypot(
    js-implicit context: NativeContext, receiver: JSAny)(
    ...arguments): Number {
  const length = arguments.length;
  if (length == 0) {
    return 0;
  }
  const absValues = AllocateZeroedFixedDoubleArray(length);
  let oneArgIsNaN: bool = false;
  let max: float64 = 0;
  for (let i: intptr = 0; i < length; ++i) {
    const value = Convert<float64>(ToNumber_Inline(arguments[i]));
    if (Float64IsNaN(value)) {
      oneArgIsNaN = true;
    } else {
      const absValue = Float64Abs(value);
      absValues.floats[i] = Convert<float64_or_hole>(absValue);
      if (absValue > max) {
        max = absValue;
      }
    }
  }
  if (max == V8_INFINITY) {
    return V8_INFINITY;
  } else if (oneArgIsNaN) {
    return kNaN;
  } else if (max == 0) {
    return 0;
  }
  dcheck(max > 0);

  // Kahan summation to avoid rounding errors.
  // Normalize the numbers to the largest one to avoid overflow.
  let sum: float64 = 0;
  let compensation: float64 = 0;
  for (let i: intptr = 0; i < length; ++i) {
    const n = absValues.floats[i].ValueUnsafeAssumeNotHole() / max;
    const summand = n * n - compensation;
    const preliminary = sum + summand;
    compensation = (preliminary - sum) - summand;
    sum = preliminary;
  }
  return Convert<Number>(Float64Sqrt(sum) * max);

가설 1: Allocate가 느린가?

먼저, 메모리를 할당/해제 반복적으로 한다면 메모리 관리 비용으로 인해 느려질 것으로 추정했습니다.

이 가설을 테스트하기 위해 메모리를 할당하는 구문(AllocateZeroedFixedDoubleArray) 을 제거하고 arguments를 직접 사용하게 변경했습니다.

그러나, 퍼포먼스가 드라마틱하게 증가하진 않았습니다.

가설 2: ToNumber_Inline 의 비용이 높은가?

ToNumber 표준을 보면 다양한 경우를 분기 처리하고 있어 비용이 클 수 있다는 가설을 세웠습니다.

이 가설이 맞는지 테스트 하기 위해 파라미터의 값이 Number 타입인지 체크하고, Float64로 UnsafeCast하여 테스트를 진행했습니다.

성능 향상이 0.5~2% 대로 미미했기 때문에 이 가설은 문제의 핵심 원인이 아니라고 판단했습니다.

가설 3: 부차적인 연산의 비용이 높은가?

위 구현을 보면 빗변을 계산하는 구문 이외에 절댓값으로 변환하는 것과 Kahan summation 알고리즘을 수행하는 등 별도의 연산이 포함되어 있습니다. 저는 이 부차적인 연산이 성능에 영향을 줄 것 이라는 가설을 세웠습니다.

이러한 알고리즘 구현을 제거하고, 테스트하기 위해 위 함수 상단에 파라미터가 2개인 경우 sqrt( a ^ 2 + b ^ 2) 만 계산하도록 구현하고 테스트 해봤습니다.

  if (length == 2) {

	  let max: float64 = 0;

    const a = Convert<float64>(ToNumber_Inline(arguments[0]));
	  const b = Convert<float64>(ToNumber_Inline(arguments[1]));

    if (a == V8_INFINITY || b == V8_INFINITY) {
      return V8_INFINITY;
    }

    max = Float64Max(a, b);

    if (Float64IsNaN(max)) {
      return kNaN;
    }

    if (max == 0) {
      return 0;
    }

    return Convert<Number>(
        Float64Sqrt((a / max) * (a / max) + (b / max) * (b / max)) * max);
}

테스트 결과 놀라울 만큼 빨라졌습니다.

Method	Runtime
*	104.041ms
hypot	814.667ms
**	670.709ms
pow	674.583ms

위 구현은 간단하게 구현하기 위해 arguments 길이가 2인 경우에만 실행되도록 구현했습니다.

위 테스트에 이어서 위 길이가 2인 경우만 계산하는 로직을 제거하고, 아래에 있는 구현에 부차적인 연산을 제거하는 테스트를 수행했습니다.

그러나 이번 테스트에서는 다시 속도가 느려졌습니다.

따라서, 부차적인 로직을 제거한 것이 빨라진 것의 원인이라고 보기는 어려울 것 입니다.

현상 분석: 왜 빨라진 것 인가

이제 성능이 향상되는 현상을 발견했습니다.

이 현상의 원인을 설명할 수 있다면 이 최적화에 대한 CL(PR과 같은 개념입니다)을 제출할 수 있을 것입니다.

우선 코드에서 크게 사라진 부분이라고 한다면, 반복문일 것입니다.

반복문이 원인일 가능성이 높아진 상황에서 실험을 해보기로 합니다. 아래의 코드를 Math.hypot 구현체에 추가 했습니다.

for(i = 0; i<length; i++) {
}

위 코드의 삽입으로 200ms 의 지연이 발생 했습니다.

이 현상에 대해 두 가지의 가설을 세워 검증했습니다.

가설 4: torque로 작성되어 CSA로 컴파일된 loop는 비효율적인가?

이 가설은 “CSA(Code Stub Assembler)로 컴파일 되는 torque는 CSA로 직접 구현한 것 보다 for loop 동작이 느리게 수행된다”는 가설입니다.

마치 어셈블리로 직접 구현 하면 일부 구간에선 빠르게 동작할 수 있는 것처럼, 이 가설을 검증하기 위해 CSA로 직접 구현해 비교해 보기로 합니다.

CSA로 구현하여 비교한 결과 평균적으로 아주 약간 빠른걸 알 수 있었습니다.

그러나 이 차이는 미미하기 때문에 성능 저하의 핵심 원인은 아닐 것입니다.

가설 5 및 결론 : Loop의 숨겨진 cost가 있는가?

반복문의 유무로 큰 차이가 발생하는 이유에 대해 면밀히 고민해 보다가 낸 결론입니다.

반복문에는 숨겨진 비용이 존재합니다.

반복문의 진입 시 비교하고, 반복 탈출을 위하여 n 번 즉 n+1, 증가 연산도 마찬가지로 반복문 내에서 n번 실행되게 됩니다.

다시 Math.hypot 구현체로 돌아가 살펴보면, 총 두 개의 반복문이 있는 것을 알 수 있습니다.

그렇다면 파라미터가2개일 때 6번의 비교 연산과 4번의 증가 연산이 반복문을 위해 소비되고 있음을 알 수 있습니다.

여기서 실행 횟수 N이 커지게 될 경우 N * 6 만큼 연산량이 소비될 수 있으며 이에 따라 실행시간이 차이 난 것입니다.

개선

따라서, 파라미터의 길이가 3보다 작은 경우 반복문 없이 실행되도록 하여 최적화를 했습니다.

이 과정에서 파라미터가 3개인 경우에는 Kahan summation 알고리즘을 방정식으로 정리하여 적용했습니다.

  try {
    return FastMathHypot(arguments) otherwise Slow;
  } label Slow {
    const length = arguments.length;
// ...

FastMathHypot의 전체 구현체는 여기서 살펴보실 수 있습니다.

결론

아래는 최적화 이후 실행 시간입니다.

Method	Runtime
*	104.041ms
hypot	814.667ms
**	670.709ms
pow	674.583ms

위 결과에서 볼 수 있듯 최적화 이전 실행시간(1584.417ms) 대비 약 194% 향상되었음을 알 수 있습니다.

여러 번 실행해 본 결과 180~200%의 성능 향상 폭을 얻었음을 알 수 있었습니다.

이번 최적화에서는 메모리의 할당부터, ToNumber, 부차적인 연산, For loop와 관련된 가설을 세웠습니다. 이 가설들을 검증해 가며 for loop 관련 가설이 옳은 가설임을 알게 되었습니다. 여기서 loop의 숨겨진 비용을 찾아냈고 그 비용을 제거하여 V8을 개선했습니다.

여기서 배울 수 있었던 점은 반복문에는 반복문 자체를 위한 비용이 있고, 이 비용은 상황에 따라 큰 오버헤드로 작용할 수 있다는 점이겠습니다.

마지막으로,

이 글을 퇴고 해주신 김현영 님께 감사인사 드립니다.

V8에 Float16 관련 기능 추가한 첫번째 이야기

2024-03-03T09:00:00+00:00

오늘 V8에 Float16과 관련된 기능을 머지했습니다. (Float16은 IEEE754에서 정의하는 반정밀도 부동소숫점입니다.)

CL: https://chromium-review.googlesource.com/c/v8/v8/+/5082566

Javascript 엔진에 Float16Array, DataView.getFloat16, DataView.setFloat16, Math.fround16 을 추가했습니다.

변화한 파일은 총 82개, -409 +1385 에 달하는 꽤 사이즈가 큰 변화였습니다.

이슈를 잡고 머지하기까지 거의 6개월에 걸친 시간이 걸렸네요.

2023년 7월, 주로 Blink에 기여하며 CSS/HTML에 한정되어 있는 기여 대상을 V8을 통해 Javascript에 기여하겠다는 방향을 새롭게 정했습니다.

이미 Blink에 다수 기여하며 커미터 권한을 가지고 있어 Chromium 워크플로우에 익숙하기 때문에 적절한 난이도의 이슈를 잡고 해결해 나가면서 지식을 확장하면 되겠단 판단을 했습니다.

그렇게 Implement Float16Array 라는 이슈를 발견했고, ArrayBuffer와 전반적인 메모리 관리를 배울 수 있겠다는 생각과, 가뭄에 단비처럼 나타난 구현 테스크란 점을 고려해서 이슈를 붙잡았습니다.

구현을 준비하고 구현하고, 코드 리뷰하는 과정에 다양한 우여곡절이 많았습니다.

전부 담지는 못하겠지만 짤막하게 과정을 적어봤습니다.

구현 과정

Stage-3 표준 살펴보기

https://tc39.es/proposal-float16array/

우선 표준을 살펴봤습니다.

Float16Array는 Stage 3 proposal로써 구현되기를 기대하는 기능으로 표준을 보며 구현하면 될 것이라는 생각을 했습니다.

표준 내용을 보면 알겠지만, 각 타입별로 저장하거나 불러올 때 변환 시 float16 타입이 추가된 점과 DataView, Math에 관련 기능이 추가된다는 점을 알 수 있습니다.

구현 지점 찾기

코드를 보며 구현 지점을 찾았습니다. V8은 DRY 원칙을 최대한 지키려고 하여 매크로를 적극적으로 사용하고 있습니다.

이런 식으로 말이죠.

가끔 chromium source에서 심볼을 못 따라가고 메크로로 prefix나 suffix가 붙는 것 때문에 처음 보면 검색하기 어렵다는 경험을 했습니다. 다만 시간이 흘러 학습되고 나서 구현할 때는 상당히 편하기도 했습니다.

저기에 타입을 추가하면서 컴파일 에러가 발생하는 지점을 찾아 미구현 사항을 보완하며 수정지점을 찾으면 되겠다는 전략을 세웠습니다.

Float16 에 대하여

위 이미지에서 볼 수 있듯이 C type을 지정해야 합니다. 우선 모든 빌드 Target에 대해 float16을 지원하는지 미지수였고, 이 부분은 컴파일러 옵션과 로우레벨 최적화 관련된 변화가 필요할 것으로 판단했습니다.

관련 변화를 한 번에 하려고 RISC-V 스펙과 x86 스펙을 보면서 구현을 시도하려 했었는데, 생각보다 변화가 필요한 영역이 너무 넓어지는 경향이 있어 관련한 변화는 분리가 가능한 문제로 보고 분리하여 구현하는 게 좋겠다는 의견과 함께 Google의 V8 커미터인 syg@ (감사합니다!) 에게 질문 메일을 남겼고 답변으로 방향을 어느 정도 잡게 되었습니다.

따라서 컴파일러 및 언어(혹은 하드웨어)가 지원하는 Native float 16 타입을 사용하지 않고, 2바이트의 같은 크기를 가진 uint16_t 타입을 활용하여 float16을 구현해야겠단 생각을 했습니다.

변환 로직 구현하기

처음에는 변환 알고리즘을 찾고 이해하는데 시간을 많이 썼습니다. 이미 구현되어 있는 구현체는 꽤 있었고 비트연산과 float 곱셈의 원리를 이용하여 구현된 로직을 사용하기로 했습니다. (이는 추후 코드 리뷰로 이미 Chromium 내에서 사용하던 모듈로 변경됩니다.)

C++로 구현된 구현체뿐만 아닌 CSA (Code Stub Assembler)로도 해당 구현체를 구현해야 합니다.

어셈블리어로 구현하는 느낌과 유사했습니다. 조금 더 편한 어셈블리어 느낌을 받았습니다.

따라서 아래처럼 C++ 구현체를 CSA 코드로 구현하는 작업도 진행했습니다.

변환 로직 적용

이제 메모리에 넣고 뺄 때 위 변환 로직을 적용해야 합니다.

v8에서는 그 부분을 Template Specialization으로 적극 구현되어 있습니다.

따라서 값을 메모리에 넣고 뺄 때 부동 소수점 타입(double, float)을 변환하여 저장할 수 있도록 구현했습니다.

위 이미지는 elements.cc에서 double 타입을 float16 으로 표현된 uint16_t 값을 반환하는 Template Specialized 함수입니다.

또한 표준에서 정의하는 DataView.getFloat16, DataView.setFloat16, Math.fround16 함수에 해당 변환 로직을 적용합니다.

아래는 DataView의 getFloat16 구현체입니다. torque 라는 언어로 구현되어 있고 컴파일하면 CSA코드로 컴파일됩니다. 따라서 CSA로 구현된 구현체를 연결할 수 있습니다.

JIT 막기: Deoptimize

V8의 Turbofan과 Maglev 파이프라인을 타게 되면 머신코드로 컴파일되는 JIT이 동작하게 됩니다. 아직 float16 타입은 머신에서 지원하지 않고, 추후 개선을 위해 소프트웨어적으로 구현해야 하므로 바이트코드 그래프를 만들 때 의도적으로 float16 타입이면Deoptimize 노드를 추가하여 최적화 동작을 막도록 했습니다.

JIT 지원을 임시로 막기 위해 별도의 조건 없이 Deoptimize 노드를 추가하면 deopt loop을 형성하는 문제가 있는데 해결을 위해 작업을 진행할 예정입니다.

테스트코드

이미 Test262, mjsunit 테스트를 통해 TypedArray에 대한 테스트가 충분히 진행되고 있었습니다. 저는 여기에 Float16Array를 적용하여 실패하는 지점을 보완하고 Float16타입의 특성을 가진 테스트 케이스를 추가하였습니다.

코드 리뷰

코드 리뷰 과정이 거의 3개월 걸린 것 같습니다. 변화량도 많고 비동기로 커뮤니케이션을 진행하다 보니 많은 시간이 소요되었습니다. 리뷰를 통해 많은 부분 개선되고 더 깔끔하게 구현체가 정리된 것 같습니다.

이 글을 빌어 제 CL을 리뷰해 준 syg@, cbruni@, dmercadier@, dmercadier@ 에 감사 인사드립니다!

마무리

각 단계마다 길을 잃기도 하고 잘못된 길을 들어가서 한참 헤매는 과정을 겪었습니다. 덕분에 시간은 많이 들었지만 v8의 내부 구조와 경로를 많이 파악할 수 있었습니다. 사이즈도 크고 리뷰도 오래 걸려 처음 v8에 기여를 시작한 CL이지만 다른 기여들이 먼저 머지되었었네요.

직접 d8을 컴파일 하게 되면 --js_float16array 라는 옵션을 발견할 수 있습니다! 그 옵션과 함께 Float16Array을 사용해 볼 수 있습니다.

실제 유저에게 이 기능이 노출되는 건 아마도 시간이 소요될 것 같습니다. 여전히 Turbofan optimization Loop, Hardware support 등 해결해야 할 문제가 있기 때문입니다. 이 지점도 꾸준히 기여하여 언젠간 Float16Array가 세상에 등장할 수 있도록 노력하겠습니다.

JS 클로저는 표준에서 어떻게 다루고 있을까?

2024-01-30T03:00:00+00:00

클로저란 무엇일까?

간략하게 알고 있는 것은 outer function에서 선언한 요소를 inner function에서 접근 가능한 동작을 말한다는 것이었다.

왜 클로저라고 불릴까? 위키피디아에 따르면 Peter Landian이 1964 년에 그의 SECD 머신에서 사용되는 개념으로 클로저라는 용어를 처음 정의했다고 한다.

이 동작은 정확히 어떻게 보장받고 있는 걸까?

ECMA Script를 살펴보자. ES15(2024)를 기준으로 한다.

JS에서는 모든 함수는 Function object로 객체화된다.

여기서 사용되는 표준을 하나씩 살펴보자

함수가 객체화될 때 10.2.11 FunctionDeclarationInstantiation 라는 추상 연산에 의해 객체화가 된다.

여기서 추상 연산은 표준에서 사용되는 함수라고 생각하면 편하다.

그리고 [[형식으로]] 표기된 공간은 internal slot이라고 불리는데 js에서는 노출 안되는 프로퍼티라고 생각하면 편하다.

함수는 객체다

실제로 함수가 선언되면서 객체화가 되는지 살펴보자.

표준을 살펴보면, 함수의 syntax 분석이 완료되면 syntax tree는 각각 타입에 맞게 떨어진다, 각각 FunctionBody, ConciseBody, GeneratorBody, AsyncFunctionBody, AsyncConciseBody로 등으로 부른다.

이 중에서 한 가지 케이스를 살펴보자.

FunctionBody : FunctionStatementList
1. Return ? **EvaluateFunctionBody** of FunctionBody with arguments functionObject and argumentsList.
ConciseBody : ExpressionBody
...이하생략

15.2.3 Runtime Semantics: EvaluateFunctionBody 표준을 따라가 보면, 해당 표준에서 드디어 위에서 언급한 연산이 호출되는걸 볼 수 있다.

FunctionBody : FunctionStatementList
1. Perform ? **FunctionDeclarationInstantiation**(functionObject, argumentsList).
2. Return ? Evaluation of FunctionStatementList.

자 그럼 실제 함수 선언이 이 연산을 통해 객체화가 된다는 사실을 알았다.

값 참조

클로저에 대해 더 알아보기 전에, 함수 내에서 값을 참조할 때 어떤 일이 일어나는지 살펴보자

값을 참조한다는 것은 함수 내의 assign 로직을 살펴보면 좋을 것이다,

13.15.2 Runtime Semantics: Evaluation 표준을 살펴보면 assign 로직이 어떻게 평가되는지 알 수 있다. 평가되는 로직을 살펴보면 GetValue라는 연산을 호출하는 것을 알 수 있다.

6.2.5.5 GetValue 이 표준을 살펴보자.

4.c를 잘 보면 GetBindingValue라는 연산을 수행하게 된다.

9.1.1.2.6 GetBindingValue ( N, S ) GetBindingValue의 표준을 살펴보면 다음처럼 [[BindingObject]] Internal Slot 값에서 가져온다는 사실을 알 수 있다!

함수 객체화 표준: lexical scope에 접근한다

다시 함수가 객체화되는 곳을 살펴보자

LexicallyScopedDeclareations of code를 돌면서 lexEnv에 값을 설정하는 것을 볼 수 있다.

그렇게 36.c 에 가면 9.1.1.2.5 SetMutableBinding ( N, V, S ) 을 호출하게 되는데,

위에서 서술했던 GetValue에서 사용하는 같은 internal 슬롯에 값을 쓰는 것을 볼 수 있다.

정리하자면 함수가 선언되며 객체가 되는데, 이 객체가 생성되는 과정에서 생성 당시의 Lexical Scope에 존재하는 선언을 함수 오브젝트의 internal slot [[BindingObject]] 에 집어넣고, 함수 호출이 일어난다면 assign 등, 식별자의 값을 사용해야 할 때 해당 [[BindingObject]]에 있는 값을 가져와서 활용하는 것이다.

 // outer function object 생성, [[BindingObject]]은 global 스코프 내 정의된 값
function outer() {
  let test = 0
  // iner function object 생성, [[BindingObject]]에 들어있는 global 스코프에 정의된 값 + test
  return function inner() {
     // GetValue를 사용하여 [[BindingObject]]의 test값을 가져와 반환 후 값 증가
     return test++; 
  }
}

const func = outer()

//  0 출력. 왜냐하면 "[[BindingObject]]" 에는 outer 정보까지 다 들어있는 "객체"가 반환되기 때문
console.log(func())

// 1 출력. 왜냐하면 내부의 슬롯의 값이 업데이트되었기 때문
console.log(func()) 

우리는 이 일련의 동작 과정과 표준에서 보장하는 클로저 라는 기능을 사용하고 있다.

실제로 v8 구현체가 표준을 따르는지 간략히 살펴보았는데, 표준과 완전히 1대1 대응되진 않고, 전반적인 흐름이 표준을 만족하는 것으로 보인다.

아래는 큰 흐름에서 두 가지 지점이다.

함수를 파싱하는 부분

런타임에서 값을 찾는 부분

값을 사용하는 지점이 많다 보니 값을 찾는 부분을 명확히 전부 파악하기에 시간이 많이 소요될 것 같다.

JS array sort((a,b) => a < b) 가 정렬을 보장하지 않는 이유

2024-01-28T15:00:00+00:00

얼마 전에 crbug에서 기여할 항목을 찾다가 신기한 이슈를 발견했다.

https://bugs.chromium.org/p/v8/issues/detail?id=14595

제보된 이슈의 내용을 요약하면 Array.prototype.sort의 동작과 TypedArray.prototype.sort 과 동작이 다르고, 다른 js 엔진과 compare function 동작이 다르다는 것이다. 이게 어떻게 된 일일까?

다음의 코드를 보았을 때 어떤 실행 결과를 기대하는가?

[2,1,5,6,7].sort((a,b)=>(a<b))

얼핏 보기에는 정렬이 되기를 기대할 것이다.

하지만 결과는 v8 을 기준으로 정렬되지 않는다.

JSC, SpiderMonkey는 정렬을 해준다.

이 차이는 왜 발생할까?

ES15(2024) 표준을 살펴보면

5. Let sortedList be ? SortIndexedProperties(obj, len, SortCompare, SKIP-HOLES).

실질적으로 정렬을 수행하는 내용은 SortIndexedProperties 에서 수행하는 것으로 보인다.

해당 내용을 살펴보자.

표준에서 abstract operation은 표준에서 쓰는 함수로 읽으면 편하다.

4. Sort items using an implementation-defined sequence of calls to SortCompare. If any such call returns an abrupt completion, stop before performing any further calls to SortCompare and return that Completion Record

여기서 주목할 단어는 implementation-defined다. 이 말은 구현 측에서 정의하도록 열어둔다는 뜻이다.

표준 내용을 조금 더 읽어보면 해당 implementation-defined 만족해야 할 내용이 있다.

There must be some mathematical permutation π of the non-negative integers less than itemCount, such that for every non-negative integer j less than itemCount, the element old[j] is exactly the same as new[π(j)].

Then for all non-negative integers j and k, each less than itemCount, if ℝ(SortCompare(old[j], old[k])) < 0, then π(j) < π(k).

만족해야 할 내용을 요약하면 다음과 같다.

배열의 길이보다 작은 모든 정수 j, k가 있다고 할 때,

a = arr[j], b = arr[k], compareFunction(a, b) 호출이 반환한 숫자가 0보다 작은 경우 a, b 순이여야 한다.

다시 원래의 문제로 돌아가 보자

[2,1,5,6,7].sort((a,b)=>(a<b))

compare 함수가 반환하는 값은 어떤 값일까?

false 혹은 true다. 이는 ToNumber 스팩에 의해서 최종적으로 0과 1을 소비하게 된다.

정렬을 수행하는 implementation-defined 이 요구하는 요구사항을 만족하는 값이 아니다. 따라서 이는 구현 측에서 결정이 되며 정렬을 수행하지 않는 것 또한 표준을 만족한다.

따라서 이 이슈는 버그로 분류되진 않는다. 구글의 JS 리더 syg@의 더블체크를 받으면서 이슈를 닫았다.

Jest는 Code Coverage를 어떻게 측정할까? (V8)

2023-09-23T00:00:01+00:00

Motivation

회사에 커버리지를 중심으로 한 워크플로우를 만들고자 하는데 커버리지가 정확히 무엇인지 알고자 했다.

Introduction

이 글을 통해서 jest --CollectCoverage --coverageProvider=v8는 어떻게 커버리지를 측정하는지 jest 를 시작으로 가볍게 v8을 살펴보며 커버리지를 어떻게 측정하는지 알게 될 것이다.

컴파일러 이론을 미리 알고 보면 더 읽기 수월할 것이다.

Coverage?

소프트웨어 공학에서 코드 커버리지는 특정 Test Suite가 실행될 때 프로그램의 소스 코드가 실행되는 정도를 백분율로 측정한 것이다 - 위키피디아

우리는 jest를 통해서 코드를 테스트하고 있으며 —CollectCoverage 옵션을 통해 테스트 커버리지를 측정할 수 있다.

export function testFunc(a: number, b: number) {
  if (a > 20) {
    return 0;
  }
  return a + b;
}

import { testFunc } from "~/hooks/func";

it('test', ()=> {
  expect(testFunc(10, 20)).toBe(30);
})

Coverage in jest

이 커버리지는 어떻게 측정하고 있는 걸까? 그리고 무엇일까?

V8을 기준으로 설명해 보고자 한다.

Jest는 내부적으로 collect-v8-coverage 패키지를 쓴다

내부 구현체를 보면

async startInstrumenting() {
    this.session.connect();

    await this.postSession('Profiler.enable');

    await this.postSession('Profiler.startPreciseCoverage', { // Start
      callCount: true,
      detailed: true,
    });
  }

Start로 표현된 Profiler.startPreciseCoverage Chrome Devtools Protocol을 사용하여 커버리지 측정을 진행한다.

이는 V8의 커버리지 측정 기능을 활용하기 위해 V8에 요청을 보내는 명령어로 아래의 링크에서 구체적인 내용을 확인 할 수 있다.

https://chromedevtools.github.io/devtools-protocol/tot/Profiler/

커버리지는 저 옵션을 통해 가져오게 되는 걸 알게 되었다.

구체적으로 저 프로토콜을 활용해 어떻게 커버리지를 측정하고 있을까?

아래는 해당 프로토콜을 이용해 아래 “test 함수의” 커버리지를 계산하는 예제다.

const { Session } = require("inspector");

const { promisify } = require("util");

global.session = new Session();
const postP = promisify(global.session.post.bind(global.session));

async function main() {
  global.session.connect();
  await postP("Profiler.enable");

  await postP("Profiler.startPreciseCoverage", {
    callCount: true,
    detailed: true,
  });

  function test(a, b) {
    if (a > 20) {
      return 0;
    }
    return a + b;
  }

  let l = 10;
  var v = 20;

  console.log(test(l, v));

  console.log(test(l, v) === 30);

  console.log(test(l + 20, v) !== 20);

  const r = await postP("Profiler.takePreciseCoverage");

  await postP("Profiler.stopPreciseCoverage");
  await postP("Profiler.disable");

  const file = r.result.find((f) => f.url.startsWith("file://"));
  console.log(JSON.stringify(file, null, 4));
}

main();

이 코드를 nodejs환경에서 실행하면 다음의 결과를 콘솔에 출력할 것이다.

{
    "scriptId": "481",
    "url": "file:///Users/seokho/workspace/chromium/playground/v8_test.js",
    "functions": [
        {
            "functionName": "main",
            "ranges": [
                {
                    "startOffset": 182,
                    "endOffset": 777,
                    "count": 1
                }
            ],
            "isBlockCoverage": false
        },
        {
            "functionName": "test",
            "ranges": [
                {
                    "startOffset": 372, // byte offset
                    "endOffset": 454,
                    "count": 1
                },
                {
                    "startOffset": 409,
                    "endOffset": 431,
                    "count": 0
                }
            ],
            "isBlockCoverage": true
        },
        {
            "functionName": "",
            "ranges": [
                {
                    "startOffset": 699,
                    "endOffset": 729,
                    "count": 0
                }
            ],
            "isBlockCoverage": false
        }
    ]
}

여기서 볼 수 있듯이 몇 번 호출되었는지 블록 커버리지인지 여부를 포함한 정보를 소스레벨에서 조회할 수 있게 된다. offset은 바이트 단위로 소스코드 내에서의 위치 정보를 알 수 있다.

Compiler overview

아래 내용은 컴파일러의 동작에 대한 대략적인 이해가 있다면 더 이해하기 수월할 것이다.

아래 이미지를 통해 간략히 설명하고 넘어갈 것이다.

컴파일러는 다양한 파이프라인을 가지고 있는데 소스코드를 받아 중간의 AST를 구성하게 된다.

이 AST를 이용하여 (v8 turboshaft)IR; Intermediate Representation을 만드는데 여기까지를 컴파일러의 프론트엔드라고 부른다.

만들어진 IR을 입력으로 받아 목적코드를 만들거나 바이트코드를 생성하는 단계를 컴파일러의 백엔드라고 불린다. 이를 통해 소스코드가 VM과 네이티브 머신에서 실행될 수 있는 형태로 변화하는 것이다.

정리하자면, 코드를 트리로 만들고 트리를 중간 표현식으로 만들고, 중간 표현식을 통해 목적코드를 생성하는 과정을 거쳐 컴파일러는 코드를 컴파일한다.

How to check coverage in V8

그렇다면 이를 실행시켜주는 V8은 이 실행 여부를 어떻게 계산하고 있을까?

V8은 두 가지 방식으로 커버리지를 측정할 수 있게 지원한다.

Best effort
1. 실제 실행 성능에 큰 영향을 주지 않지만 GC등에 의해 데이터를 잃을 수도 있다.
  1. Profiler.getBestEffortCoverage()
Precise coverage insurance
1. GC로 데이터를 잃지 않고 정확한 실행 횟수 등을 얻을 수 있지만 실행 성능 등에 영향을 받을 수 있다.
  1. Profiler.startPreciseCoverage(callCount, detailed)

Best-effort coverage v8의 메커니즘을 활용하는 방식이다.

첫 번째로 호출 카운터라고 불리는 요소를 이용한다.

함수는 각각 v8의 ignition 인터프리터를 통해 호출되는데 함수가 호출될 때 마다 feedack vector의 호출 카운터를 증가시키도록 하는 방법이다.

두 번재는 재활용 메커니즘은 “함수의 소스 범위를 알아내는 것이다.

커버리지를 기록하고자 할 때 호출 카운터는 어떤 파일과 연관되는지 정보가 필요하다. 이때 Function.prototype.toString을 통해 함수의 위치를 알아낸 뒤, 부분 문자열을 추출해 내부적으로 함수의 시작과 끝 지점을 알 수 있다.

따라서 Best Effort 커버리지 측정 방식은 실행 환경에서 사용되는 부산물(?) 들을 재활용해 특정하는 방식이기 때문에 성능상 영향이 적다.

하지만 대략적인 커버리지를 알 수 있으며 GC나 기타 최적화에 의해 가려지기도 한다는 단점이 있다.

Precise coverage는 Block 단위 커버리지라고도 불리는데, 이는 각각의 expression block에 대한 커버리지를 한다는 이야기가 된다. 예를 들어 if 절의 than 블럭과 else 블럭에 대한 각각의 측정을 한다는 것이다.

Best effort도 호출 카운터를 이용하기에 오해할 수 있는데, 그때 사용되는 호출 카운터는 소스 범위만을 특정할 수 있어 블럭 단위의 정밀한 측정을 이야기하는 것은 아니다.

Precise Coverage 측정은 v8 컴파일러가 AST를 분석하면서 Conditional Block을 Bytecode generation 할 때 IncBlockCounter 명령어를 집어넣는다. 이 명령어가 실행되냐에 따라 Call count를 도출할 수 있고, 이를 통해 블럭단위의 커버리지를 측정할 수 있는 것이다.

See with example

이번 단락에서는 위에서 설명한 개념이 어떻게 실제로 동작하는지 볼 것이다.

다음 함수에 대해

커버리지를 측정한다고 가정해본다.

function test(a, b) {
    if(a > 20) {
      return 0
    } 
    return a + b;
  }
  
  let l = 10
  var v = 20

console.log(test(l,v))

console.log(test(l, v) === 30)

console.log(test(l + 20, v) !== 20)

V8 컴파일러 프론트엔드는 이 코드를 파싱하면서 AST를 구성할 것이다.

아래 명령어를 통해 위 코드의 AST를 출력해보자.

./d8 --print-ast ~/workspace/chromium/playground/test.js

[generating bytecode for function: test]
--- AST ---
FUNC at 13
. KIND 0
. LITERAL ID 1
. SUSPEND COUNT 0
. NAME "test"
. PARAMS
. . VAR (0x158832470) (mode = VAR, assigned = false) "a"
. . VAR (0x1588324f0) (mode = VAR, assigned = false) "b"
. DECLS
. . VARIABLE (0x158832470) (mode = VAR, assigned = false) "a"
. . VARIABLE (0x1588324f0) (mode = VAR, assigned = false) "b"
. IF at 24 // BLOCK
. . CONDITION at 29 // BLOCK
. . . GT at 29 // BLOCK
. . . . VAR PROXY parameter[0] (0x158832470) (mode = VAR, assigned = false) "a"
. . . . LITERAL 20 // BLOCK
. . THEN at -1 // BLOCK
. . . BLOCK at -1 // BLOCK
. . . . RETURN at 41 // BLOCK
. . . . . LITERAL 0 // BLOCK
. RETURN at 57// BLOCK 
. . ADD at 66
. . . VAR PROXY parameter[0] (0x158832470) (mode = VAR, assigned = false) "a"
. . . VAR PROXY parameter[1] (0x1588324f0) (mode = VAR, assigned = false) "b"

AST의 Block으로 표현한 부분이 함수의 블럭, 조건 등에 의한 한 블럭들이 될 것이다.

그러면 위 AST를 통해 만들어진 결과물은(IR; Intermediate Representation)은 컴파일러의 백엔드로 전달되어 아래와 같은 바이트코드를 만들어 낼 것이다. (아마도 IR 표현에는 해당 로직이 포함되어 있을 것이다.)

아래는 컴파일러가 해당 AST, IR을 전달받아 생성한 목적코드인 Bytecode (VM의 어셈블리어)다.

node --print-bytecode --print-bytecode-filter="test" ~/workspace/chromium/playground/v8_test.js

seokho@Dave ~/workspace/chromium/src/out/Default % node --print-bytecode --print-bytecode-filter="test" ~/workspace/chromium/playground/v8_test.js
[generated bytecode for function: test (0x00a7d39a6811 <SharedFunctionInfo test>)]
Bytecode length: 21
Parameter count 3
Register count 0
Frame size 0
OSR urgency: 0
Bytecode age: 0
  385 E> 0xa7d39b8b88 @    0 : b3 00             IncBlockCounter [0]
  398 S> 0xa7d39b8b8a @    2 : 0d 14             LdaSmi [20]
  403 E> 0xa7d39b8b8c @    4 : 6e 03 00          TestGreaterThan a0, [0]
         0xa7d39b8b8f @    7 : 99 06             JumpIfFalse [6] (0xa7d39b8b95 @ 13)
         0xa7d39b8b91 @    9 : b3 01             IncBlockCounter [1]
  417 S> 0xa7d39b8b93 @   11 : 0c                LdaZero
  425 S> 0xa7d39b8b94 @   12 : a9                Return
         0xa7d39b8b95 @   13 : b3 02             IncBlockCounter [2]
  437 S> 0xa7d39b8b97 @   15 : 0b 04             Ldar a1
  446 E> 0xa7d39b8b99 @   17 : 39 03 01          Add a0, [1]
  450 S> 0xa7d39b8b9c @   20 : a9                Return
Constant pool (size = 0)
Handler Table (size = 0)
Source Position Table (size = 19)
0x00a7d39b8ba1 <ByteArray[19]

명령어 IncBlockCounter 가 블록에 추가된 것을 확인할 수 있다.

IncBlockCounter(slot) 명령어는 해당 블록 슬롯의 call counter를 증가시킨다.

이 정보를 devtools protocol을 통해 결과로 가져온 것이 첫 단락에서의 커버리지 데이터인 것이다.

References

https://v8.dev/blog/javascript-code-coverage

https://chromedevtools.github.io/devtools-protocol/tot/Profiler/#method-startPreciseCoverage

https://docs.google.com/document/d/1wCydi2HEZRF0skDeLb6CH0abZnTyVo5Vz5u-jhwi7es/mobilebasic

CSS 삼각 함수를 배포했다

2022-12-20T00:00:01+00:00

CSS 삼각 함수를 배포했다.

Feature Entry: https://chromestatus.com/feature/5165381072191488

7월쯤 시작한 Chromium에 CSS에 삼각함수를 구현하는 프로젝트 “CSSTrigonometricFunctions”를 마무리했다.

취미개발로 주로 일요일과 출근시간 전, 퇴근 후 작업했다.

CSS 삼각함수는 다음의 함수를 구현하는 프로젝트다.

MDN: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Functions#trigonometric_functions

함수들은 css-values-4 스팩에 정의되어 있다.

2018년에 W3C 스팩 초안이 만들어졌고, 2020년에 기능을 정의하는 삼각함수 챕터 ”11.4. Trigonometric Functions: sin(), cos(), tan(), asin(), acos(), atan(), and atan2()” 가 등장했다.

올해 초 구현을 계획하다 리팩토링이 겹쳐 다른 작업들 위주로 개발하다 7월부터 실제 구현을 시작한 프로젝트로, Chromium 정식 기능개발 과정인 Intent to prototype과 Intent to Ship 그리고 3명의 커미터의 approved를 받아 stable로 전환하는 배포 CL이 머지되어 배포되었고, Chrome은 111 버전에 이 커밋이 포함되어 배포가 된다.

Chrome 111 버전은 2월 9일부터 16일까지 beta를 거쳐 3월 1일부터 일반 사용자들에게 업데이트 된다.

구현시 주요 내용은 삼각함수를 평가/처리하는 함수를 생성하고, 그 함수 내에서 각 함수별 처리를 추가하는 작업이 진행되었다. 삼각함수 하나당 하나의 CL(like PR)로 다뤄졌고, 관련한 WPT 테스트케이스들을 추가하게 되었다.

atan2의 경우 현재 releative-length를 처리하는 것에 기술적인 이슈(특히, 파싱 타임에서 평가가 불가능해지는 점이)들이 존재해 relative 단위를 평가/처리 하지 않고, 그냥 자신의 값을 반환하게 구현했다.

이는 주요 브라우저 엔진들인 webkit, gecko 도 동일하며, 관련한 이슈 이야기가 W3C/CSSWG 에서 논의되고 있다.

이슈들 모아보기:

Crbug: https://crbug.com/1392594
Webkit Bugzilla: https://bugs.webkit.org/show_bug.cgi?id=248513
Gecko Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1802744
W3C/CSSWG: https://github.com/w3c/csswg-drafts/issues/8169