원문: Speculative Optimizations for WebAssembly using Deopts and Inlining

— V8 Blog

원문은 CC-BY-3.0

라이선스로 제공되며, 이 글은 한국어로 번역한 2차 저작물입니다.

배경

a + b

a

b

동기

virtual

추측적 인라이닝

func_a

func_a

call_indirect

func_b

func_b

func_a

기술 심층 분석

update_feedback()

example

inlinee

inlinee

(func $example (param $iterations i32) (result i32)  (local $sum i32)  block $block    loop $loop      local.get $iterations      i32.eqz      br_if $block ;; terminate loop      local.get $iterations ;; update loop counter      i32.const 1      i32.sub      local.set $iterations      i32.const 7 ;; argument for the function call      i32.const 1 ;; table index, refering to $inlinee      call_indirect (param i32) (result i32)      local.get $sum      i32.add      local.set $sum      br $loop ;; repeat    end  end  local.get $sum)...(func $inlinee (param $x i32) (result i32)  local.get $x  i32.const 37  i32.add)

int inlinee(int x) {  return x + 37;}int (*func_ptr)(int) = inlinee;int example(int iterations) {  int sum = 0;  while (iterations != 0) {    iterations--;    sum += func_ptr(7);  }  return sum;}

example

call_indirect

inlinee

example

call_indirect

call_ref

call_ref

call_ref

WasmFuncRef

call_indirect

call

call_ref

call_indirect

return_call

return_call_ref

return_call_indirect

디최적화

1. 먼저, 현재 프로그램 상태를 저장합니다. 최적화된 코드에서 런타임으로 호출하여 이를 수행합니다.

   Deoptimizer

   는 현재 프로그램 상태를 내부 데이터 구조인

   FrameDescription

   으로 직렬화합니다. 여기에는 CPU 레지스터를 읽고 디최적화될 함수의 스택 프레임을 검사하는 작업이 포함됩니다.
2. 다음으로, 이 상태를 최적화되지 않은 코드가 이해할 수 있도록 변환합니다. 즉, 값을 올바른 레지스터와 스택 슬롯에 배치하여 Liftoff 생성 코드가 디최적화 지점에서 예상하는 값으로 만듭니다. 예를 들어, TurboFan 코드가 레지스터에 넣었던 값은 이제 스택 슬롯에 있을 수 있습니다. 기본 코드의 스택 레이아웃 및 예상 값 (디최적화 지점에 대한 "호출 규칙"이라고 할 수 있습니다)은 컴파일 중에 Liftoff가 생성한 메타데이터에서 읽어옵니다.
3. 마지막으로, 최적화된 스택 프레임을 해당 최적화되지 않은 스택 프레임으로 대체하고, 디최적화가 트리거된 최적화된 코드의 중간 지점에 해당하는 기본 코드의 중간 부분으로 점프합니다.

Deoptimize

기술 심층 분석

DeoptimizationEntry

Deoptimizer

FrameDescription

FrameDescription

DeoptimizationData

FrameDescription

FrameDescription

--trace-deopt-verbose

[bailout (kind: deopt-eager, reason: wrong call target, type: Wasm): begin. deoptimizing example, function index 2, bytecode offset 134, deopt exit 0, FP to SP delta 32, pc 0x14886e50cbb4]
  reading input for Liftoff frame => bailout_id=134, height=4, function_id=2 ; inputs:
     0: 4 ; rdx (int32)
     1: 0 ; rbx (int32)
     2: (wasm int32 literal 7)
     3: (wasm int32 literal 1)
  Liftoff stack & register state for function index 2, frame size 48, total frame size 64
     0: i32:rax
     1: i32:s0x28
     2: i32:c7
     3: i32:c1
[bailout end. took 0.082 ms]

example

iterations

4

rdx

sum

0

rbx

call_indirect

iterations

rax

sum

s0x28

Deoptimizer

call_indirect

결과

call_indirect

call_indirect

call_indirect

call_indirect

call_indirect

richards-wasm

call_ref

call_indirect

결론 및 전망

• 추측적 인라이닝이 간접 호출이 있는 경우에도 함수를 인라인하는 방법,
• 피드백이 무엇인지, 어떻게 사용되고 업데이트되는지,
• 최적화 중에 내려진 가정이 런타임에 유효하지 않을 때 어떻게 해야 하는지,
• 디최적화가 어떻게 최적화된 코드를 종료하고 함수의 실행 중간에 기본 코드로 진입할 수 있는지, 그리고 마지막으로
• 이것이 어떻게 실제 워크로드의 실행을 크게 개선하는지.

각주

1. Wasm에 대한 SIMD 확장을 고려하면 이는 TurboFan에서 사용하는 모든 128비트 벡터 레지스터도 포함합니다. ↩︎
2. 다른 경우, 상수 폴딩 후 최적화된 버전에서 값이 상수일 수 있지만, Liftoff를 위해 스택 슬롯이나 레지스터로 구체화되어야 하므로 디최적화 데이터에는 이러한 상수 값을 저장해야 합니다. ↩︎
3. 디최적화 자체 중에는 힙에 할당할 수 없습니다. 할당은 가비지 컬렉터(GC)를 트리거할 수 있으며, 스택은 GC가 검사할 수 있는 상태가 아니기 때문입니다. (GC는 스택의 모든 힙 참조를 방문하고 객체를 이동할 때 잠재적으로 업데이트해야 합니다.) ↩︎
4. 측정은 x64 워크스테이션에서 수행되었습니다. 그림은 N=21회 반복의 중앙값을 보여줍니다. ↩︎
5. 약간의 회귀가 있는 세 가지

   Matrix4Benchmark

   항목의 경우,

   call_indirect

   인라이닝을 활성화하면 우리의 휴리스틱은 16개의 간접 호출 사이트를 다른 직접 호출 사이트보다 인라인하는 것을 선호합니다. 이로 인해 인라이닝 예산이 소진되어 (즉, 결과 코드가 너무 커져 인라인을 중지) 이전보다 직접 호출의 수가 적게 인라인됩니다. 이 특정 경우에는 휴리스틱이 한 인라이닝 결정이 다른 결정보다 얼마나 유익한지 완벽하게 예측하지 못하고 최적이 아닌 결과를 초래합니다. 이 휴리스틱을 개선하는 것은 흥미로운 미래 작업입니다. ↩︎