next.js 환경에서는 메모리가 어떻게 사용 될까?

[yuiseo]

📝 프론트엔드 next.js 환경에서는 메모리가 어떻게 사용 될까?

📚 주제:
스패로우 클라우드 프론트를 구성하는 프레임워크인 next.js의 메모리는 어떻게 구성되는지 알아본다.

---

🎯 스터디 목표
메모리 구조를 학습 통해 이슈 #8 로 확장하여 현재 사용 환경에서의 힙 메모리를 제한할 수 있다.

---

📖 핵심 내용:

Next.js의 기본 메모리 관리 구조

Next.js는 Node.js 기반의 V8 엔진에서 실행된다.
JavaScript는 싱글 스레드 언어이다. 따라서 V8 역시 자바스크립트의 Context 당 하나의 프로세스를 사용한다. 단, 서비스 워커를 사용하는 경우는 워커의 개수만큼 프로세스를 증식한다고 한다.

실행중인 프로그램은 V8 프로세스에서 할당된 일정량의 메모리로 표현되는데, 이를 Resident set이라고 한다. 내부 구조는 아래 사진과 같다.

사진에서 볼 수 있듯이 크게 힙 메모리와 스택 메모리로 관리 되는 것을 확인할 수 있다.

1️⃣ 스택 메모리

스택은 메모리 영역이고 V8마다 하나의 스택을 가진다. 스택에는 정적데이터(메서드와 함수 프레임, 원시 값, 객체 포인터)가 저장된다.
V8의 스택 영역의 관리는 OS에 위임하여 관리한다. (자동으로 관리)

2️⃣ 힙 메모리

• 힙 메모리는 메모리 영역에서 가장 큰 블록을 차지하고 있다. 힙에는 객체와 동적 데이터들이 저장 된다.
• 힙은 스택과 달리 메모리가 자동으로 관리되지 않아 프로그램의 메모리가 기하급수적으로 증가할 수 있다.
• 힙에서는 메모리 관리를 위해 가비지 컬렉션이 발생할 수 있는데, **New space(Young generation)**과 Old space(Old generation) 영역에 한에서 발생한다.

📝 힙 메모리의 주요 영역

New space(Young generation)

• 새로 만들어진 모든 객체를 저장하고, 이 객체들은 짧은 생명 주기를 갖는다.
• 이 영역은 스캐벤져라는 이름의 마이너 GC를 통해 관리된다.
• New space의 크기는 --min_semi_space_size(초기값)와 --max_semi_space_size(최대값) V8엔진의 플래그 값을 사용해 조정할 수 있다.

Old spcae(Old generation)

• 스캐벤져(마이너 GC)가 두 번 순회할 동안 New space에서 살아남은 객체들이 이동하는 영역이다.
• 메이저 GC가 관리하며, 두 영역으로 나뉜다.

  1. Old 포인터 영역
     스캐벤져로부터 살아남은 객체를 가지고 있고, 이 객체들은 다른 객체를 참조한다.

  2. Old 데이터 영역

  • 데이터만 가진 객체(다른 객체 참조x)를 가진다.
  • 문자열, boxing된 숫자, doubled unboxing된 배열 등이 이 곳에 위치한다.
• �Old space의 크기는 --min_old_space_size(초기값)와 --max_old_space_size(최대값) V8엔진의 플래그 값을 사용해 조정할 수 있다.

V8의 메모리 관리 : Garbage Collection

스택은 알아서 관리되지만 힙 공간은 V8엔진이 관리하는데, 이 역할을 가비지 컬렉션이 수행한다.
가비지 컬렉션은 참조가 없는 객체들이 사용하는 메모리를 비워 새 객체를 위한 공간을 만든다.

❓ 참조가 없는 객체란?
더이상 필요가 없어서 스택으로부터 주소 참조가 발생하지 않는 객체이며,
도달 가능성(reachability)이 없는 객체라고도한다.

프로그램이 사용 가능한 것보다 더 많은 메모리가 힙에 할당될 때 메모리 부족 오류를 발생한다. 힙이 잘못 관리 되면 메모리 누수 위험이 있기 때문에, 가비지 컬렉션이 잘 관리를 하여 이를 방지 해야한다.

📍Garbage Collection의 주요 개념 - reachability(도달 가능성)

도달 가능성은 객체가 여전히 프로그램에서 접근 가능한 상태인지 여부를 판단하는 기준이다. 비지 컬렉션은 이 개념을 바탕으로 필요 없는 객체를 메모리에서 제거한다.

• 도달 가능한 객체: 루트(root, 전역 객체 등)에서부터 참조 경로가 존재하는 모든 객체는 도달 가능한 상태로 간주된다. 이들은 프로그램에서 사용될 가능성이 있으므로 가비지 컬렉션에서 제외된다.

• 도달 불가능한 객체: 루트에서 참조되지 않아 도달할 수 없는 객체는 가비지 컬렉션의 대상으로, 불필요한 메모리 공간을 차지하므로 정리된다.

• Object3는 루트로부터 도달 가능한 객체가 아니기 때문에 가비지 컬렉션의 대상이 된다.

-> Object 1, 3, 4는 서로 도달할 수 있지만 문제는 루트에서 이 객체들에 도달할 수가 없다.
그러므로 Object 1, 3, 4 모두 가비지컬렉션의 대상이 된다.

---

💡 참고 자료:

• https://speakerdeck.com/deepu105/v8-memory-usage-stack-and-heap
• https://fe-developers.kakaoent.com/2022/220519-garbage-collection/
• https://velog.io/@seyoung8239/V8-%EC%97%94%EC%A7%84-%EB%82%B4%EB%B6%80%EC%9D%98-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EA%B4%80%EB%A6%AC
• https://gobae.tistory.com/116#V-%EC%--%--%EC%--%-C%EC%-D%--%--%ED%-E%--%--%EB%A-%--%EB%AA%A-%EB%A-%AC
• https://gobae.tistory.com/101
• https://deepu.tech/memory-management-in-v8/

[suna-ji]

JVM의 메모리 구조와 비슷하면서 다른 부분이 흥미로웠어요..!
다음 스터디에서 실질적으로 힙 메모리 관리할 수 있는 방법도 알려주신다니 기대되네요 👍 수고하셨습니다!! 🥰

[since1909]

엔진이 알아서 잘 관리해주는 메모리를 손대야할때 참 난감했던 경우가 많은데
이번 기회로 GC, heap 메모리 사용에 대해 더 공부해보게 됐습니다.
JVM 과 V8이 비슷한 정책으로 메모리를 관리하는 것으로 보이는데 왜 둘이 닮은 아키텍처를 가지게 됐는지도 찾아보면 재밌을거 같아요.