WebAssembly 가비지 컬렉션 (WasmGC)이 이제 Chrome에서 기본적으로 사용 설정됨

프로그래밍 언어에는 가비지로 수집된 프로그래밍 언어와 수동 메모리 관리가 필요한 프로그래밍 언어, 이렇게 두 가지 유형이 있습니다. 전자의 예로는 Kotlin, PHP 또는 Java가 있습니다. 후자의 예로는 C, C++ 또는 Rust가 있습니다. 일반적으로 상위 수준의 프로그래밍 언어는 가비지 컬렉션을 표준 기능으로 포함할 가능성이 더 높습니다. 이 블로그 게시물에서는 가비지로 수집된 프로그래밍 언어와 이러한 언어를 WebAssembly (Wasm)로 컴파일하는 방법을 중점적으로 살펴봅니다. 하지만 먼저 가비지 컬렉션 (GC라고도 함)이란 무엇일까요?

브라우저 지원

  • Chrome: 119 <ph type="x-smartling-placeholder">
  • Edge: 119. <ph type="x-smartling-placeholder">
  • Firefox: 120 <ph type="x-smartling-placeholder">
  • Safari: 지원되지 않음 <ph type="x-smartling-placeholder">

가비지 컬렉션

간단히 말해 가비지 컬렉션 개념은 프로그램이 할당했지만 더 이상 참조하지 않는 메모리를 회수하려는 시도입니다. 이러한 메모리를 가비지라고 합니다. 가비지 컬렉션을 구현하기 위한 여러 가지 전략이 있습니다. 그중 하나가 참조 계산으로, 목표는 메모리에 있는 객체에 대한 참조 수를 계산하는 것입니다. 객체에 대한 참조가 더 이상 없으면 객체를 더 이상 사용하지 않는 것으로 표시하여 가비지 컬렉션을 준비할 수 있습니다. PHP의 가비지 컬렉터는 참조 계산을 사용하며 Xdebug 확장 프로그램의 xdebug_debug_zval() 함수를 사용하면 자세히 살펴볼 수 있습니다. 다음 PHP 프로그램을 살펴보겠습니다.

<?php
  $a= (string) rand();
  $c = $b = $a;
  $b = 42;
  unset($c);
  $a = null;
?>

프로그램은 문자열로 변환된 랜덤 숫자를 a라는 새 변수에 할당합니다. 그런 다음 새 변수 두 개(b, c)를 만들고 a 값을 할당합니다. 그런 다음 b를 번호 42에 재할당하고 c를 설정 해제합니다. 마지막으로 a 값을 null로 설정합니다. 프로그램의 각 단계에 xdebug_debug_zval() 주석을 추가하면 작동 중인 가비지 컬렉터의 참조 카운터를 확인할 수 있습니다.

<?php
  $a= (string) rand();
  $c = $b = $a;
  xdebug_debug_zval('a');
  $b = 42;
  xdebug_debug_zval('a');
  unset($c);
  xdebug_debug_zval('a');
  $a = null;
  xdebug_debug_zval('a');
?>

위의 예시는 다음 로그를 출력하며, 여기서 각 단계 후 a 변수 값에 대한 참조 수가 어떻게 감소하는지 확인할 수 있습니다. 이는 코드 시퀀스를 고려할 때 타당합니다. (물론 랜덤 숫자는 다릅니다.)

a:
(refcount=3, is_ref=0)string '419796578' (length=9)
a:
(refcount=2, is_ref=0)string '419796578' (length=9)
a:
(refcount=1, is_ref=0)string '419796578' (length=9)
a:
(refcount=0, is_ref=0)null
드림

가비지 컬렉션과 관련된 다른 문제(예: 주기 감지)가 있지만 이 도움말에는 참조 계산에 대한 기본적인 수준의 이해가 필요합니다.

프로그래밍 언어는 다른 프로그래밍 언어로 구현됨

초창기라고 생각할 수도 있지만, 프로그래밍 언어는 다른 프로그래밍 언어로 구현됩니다. 예를 들어 PHP 런타임은 주로 C로 구현됩니다. GitHub에서 PHP 소스 코드를 확인할 수 있습니다. PHP의 가비지 컬렉션 코드는 주로 zend_gc.c 파일에 있습니다. 대부분의 개발자는 운영체제의 패키지 관리자를 통해 PHP를 설치합니다. 하지만 개발자는 소스 코드에서 PHP를 빌드할 수도 있습니다. 예를 들어 Linux 환경에서 ./buildconf && ./configure && make 단계는 Linux 런타임용 PHP를 빌드합니다. 그러나 이는 PHP 런타임이 Wasm과 같은 다른 런타임을 위해 컴파일될 수 있음을 의미하기도 합니다.

Wasm 런타임으로 언어를 포팅하는 기존 방법

PHP가 실행되는 플랫폼과 관계없이 PHP 스크립트는 동일한 바이트코드로 컴파일되며 Zend Engine에 의해 실행됩니다. Zend Engine은 PHP 스크립트 언어용 컴파일러 및 런타임 환경입니다. Zend 가상 머신 (VM)은 Zend 컴파일러와 Zend Executor로 구성됩니다. C와 같은 다른 상위 수준 언어로 구현되는 PHP와 같은 언어는 일반적으로 Intel 또는 ARM과 같은 특정 아키텍처를 대상으로 하는 최적화가 있으며 아키텍처마다 다른 백엔드가 필요합니다. 이 컨텍스트에서 Wasm은 새로운 아키텍처를 나타냅니다. VM에 JIT (Just-In-Time) 또는 AOT (Ahead-Of-Time) 컴파일과 같은 아키텍처별 코드가 있는 경우 개발자는 새 아키텍처의 JIT/AOT용 백엔드도 구현합니다. 코드베이스의 주요 부분을 각각의 새 아키텍처에 대해 재컴파일할 수 있는 경우가 많기 때문에 이 접근 방식은 합리적입니다.

Wasm이 얼마나 낮은지 감안할 때 파서, 라이브러리 지원, 가비지 컬렉션, 옵티마이저를 사용하여 기본 VM 코드를 Wasm으로 다시 컴파일하고 필요한 경우 Wasm에 대한 JIT 또는 AOT 백엔드를 구현하는 것이 좋습니다. 이는 Wasm MVP 이후로 가능해졌으며, 많은 경우 실제로 잘 작동합니다. 실제로 Wasm에 컴파일된 PHPWordPress Playground를 지원합니다. WordPress 플레이그라운드 및 WebAssembly를 사용하여 브라우저 내 WordPress 환경 빌드 도움말에서 프로젝트에 관해 자세히 알아보세요.

그러나 PHP Wasm은 호스트 언어 JavaScript의 컨텍스트에서 브라우저에서 실행됩니다. Chrome에서 JavaScript 및 Wasm은 V8에서 실행됩니다. 이는 ECMA-262에 지정된 대로 ECMAScript를 구현하는 Google의 오픈소스 JavaScript 엔진입니다. V8에는 이미 가비지 컬렉터가 있습니다. 즉, 예를 들어 Wasm에 컴파일된 PHP를 사용하는 개발자는 포팅된 언어 (PHP)의 가비지 컬렉터 구현을 가비지 컬렉터가 이미 있는 브라우저에 전달하게 되는데, 이는 말처럼 낭비입니다. 바로 이때 WasmGC가 필요합니다.

Wasm 모듈이 Wasm의 선형 메모리 위에 자체 GC를 빌드하도록 하는 기존 접근 방식의 또 다른 문제는 Wasm의 자체 가비지 컬렉터와 컴파일된 Wasm 언어의 내장 가비지 컬렉터 간에 상호작용이 없다는 것입니다. 이러한 가비지 컬렉터는 메모리 누수 및 비효율적인 수집 시도와 같은 문제를 일으키는 경향이 있습니다. Wasm 모듈이 기존 내장 GC를 재사용하도록 하면 이러한 문제를 방지할 수 있습니다.

WasmGC를 사용하여 프로그래밍 언어를 새 런타임에 포팅

WasmGC는 WebAssembly Community Group제안입니다. 현재의 Wasm MVP 구현은 선형 메모리에서 숫자, 즉 정수와 부동 소수점만 처리할 수 있으며, 제공되는 참조 유형 제안을 사용하여 Wasm은 외부 참조를 추가로 보유할 수 있습니다. WasmGC는 이제 구조체 및 배열 힙 유형을 추가하며, 이는 비선형 메모리 할당 지원을 의미합니다. 각 WasmGC 객체는 유형과 구조가 고정되어 있으므로, JavaScript와 같은 동적 언어의 최적화 위험 없이 VM이 필드에 액세스할 수 있는 효율적인 코드를 쉽게 생성할 수 있습니다. 이에 따라 이 제안은 Wasm을 대상으로 하는 언어 컴파일러가 호스트 VM의 가비지 컬렉터와 통합할 수 있도록 하는 구조체 및 배열 힙 유형을 통해 WebAssembly에 상위 수준 관리 언어에 대한 효율적인 지원을 추가합니다. 간단히 말해 WasmGC를 사용하면 프로그래밍 언어를 Wasm으로 포팅한다는 것은 프로그래밍 언어의 가비지 컬렉터가 더 이상 포트에 속할 필요가 없고 대신 기존 가비지 컬렉터를 사용할 수 있음을 의미합니다.

이러한 개선사항이 실제로 미치는 영향을 확인하기 위해 Chrome의 Wasm팀은 C, Rust, Java에서 Fannkuch 벤치마크 버전 (작동하는 대로 데이터 구조를 할당함)을 컴파일했습니다. C 및 Rust 바이너리는 다양한 컴파일러 플래그에 따라 6.1K에서 9.6K까지 다양할 수 있는 반면, Java 버전은 2.3K로 훨씬 더 작습니다. C 및 Rust에는 가비지 컬렉터가 포함되어 있지 않지만 메모리를 관리하기 위해 여전히 malloc/free를 번들로 제공합니다. 여기서 Java가 더 작은 이유는 메모리 관리 코드를 전혀 번들로 묶을 필요가 없기 때문입니다. 이는 하나의 구체적인 예에 불과하지만 WasmGC 바이너리가 매우 작을 가능성이 있으며 크기 최적화에 대한 중요한 작업 전에도 발생함을 보여줍니다.

WasmGC에서 포팅된 프로그래밍 언어의 실제 작동 방식 보기

Kotlin Wasm

WasmGC 덕분에 Wasm으로 포팅된 최초의 프로그래밍 언어 중 하나는 Kotlin/Wasm 형태의 Kotlin입니다. 다음 목록은 Kotlin팀에서 제공한 소스 코드가 포함된 데모입니다.

import kotlinx.browser.document
import kotlinx.dom.appendText
import org.w3c.dom.HTMLDivElement

fun main() {
    (document.getElementById("warning") as HTMLDivElement).style.display = "none"
    document.body?.appendText("Hello, ${greet()}!")
}

fun greet() = "world"

이제 요점이 궁금할 수 있습니다. 위의 Kotlin 코드는 기본적으로 Kotlin으로 변환된 JavaScript OM API로 구성되어 있기 때문입니다. 개발자가 이미 Android Kotlin 앱용으로 만든 UI를 기반으로 빌드할 수 있는 Compose Multiplatform과 함께 사용하면 더욱 타당해지기 시작합니다. Kotlin/Wasm 이미지 뷰어 데모에서 이에 관해 미리 살펴보고 Kotlin팀에서 제공하는 소스 코드도 살펴보세요.

Dart와 Flutter

Google의 Dart 및 Flutter팀은 WasmGC에 대한 지원을 준비하고 있습니다. Dart-to-Wasm 컴파일 작업은 거의 완료되었고 팀은 WebAssembly로 컴파일된 Flutter 웹 애플리케이션을 제공하기 위한 도구 지원을 담당하고 있습니다. 작업의 현재 상태는 Flutter 문서에서 확인할 수 있습니다. 다음 데모는 Flutter WasmGC 미리보기입니다.

를 탭합니다.

WasmGC 자세히 알아보기

이 블로그 게시물은 개략적인 개략적인 내용이고 주로 WasmGC에 대한 개략적인 개요를 제공했습니다. 이 기능에 대해 자세히 알아보려면 다음 링크를 확인하세요.

감사의 말씀

히어로 이미지: 게리 찬(Unsplash) 이 글은 마티아스 리트케, 아담 클라인, 조슈아 벨, 알론 자카이, 야콥 쿠머로우, 클레멘스 백스, 에마누엘 지글러, 레이첼 앤드류가 검토했습니다.