# 프레임 포인터의 복귀

> Clean Markdown view of GeekNews topic #13859. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=13859](https://news.hada.io/topic?id=13859)
- GeekNews Markdown: [https://news.hada.io/topic/13859.md](https://news.hada.io/topic/13859.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2024-03-18T10:00:12+09:00
- Updated: 2024-03-18T10:00:12+09:00
- Original source: [brendangregg.com](https://www.brendangregg.com/blog/2024-03-17/the-return-of-the-frame-pointers.html)
- Points: 3
- Comments: 1

## Topic Body

### Brendan의 사이트: 시작하기

- Brendan Gregg의 블로그 홈페이지는 시스템 성능, BPF 도구, Linux 성능 등에 대한 다양한 주제를 다룸.
- 최근 게시물에는 프레임 포인터의 복귀, eBPF 다큐멘터리, eBPF 관측 도구가 보안 도구가 아님 등의 내용이 포함됨.
- 블로그는 기술적인 내용과 함께 Brendan이 참여한 여러 컨퍼런스와 발표 내용도 공유함.

### 프레임 포인터의 복귀

- 프레임 포인터가 없는 시스템에서는 스택 추적이 libc 레이어에서 멈추어, 애플리케이션 프레임이 누락됨.
- Fedora와 Ubuntu는 기본적으로 프레임 포인터를 포함하여 libc를 컴파일하는 버전을 출시함으로써 이 문제를 해결함.
- 프레임 포인터는 외부 프로파일러와 디버거에 의해 사용되며, 플레임 그래프에 의해 시각화됨.

### 프레임 포인터란?

- x86-64 ABI 문서에 따르면 CPU 레지스터 %rbp를 스택 프레임의 "베이스 포인터"로 사용할 수 있음.
- 이 기술은 스택 추적을 위해 널리 사용되며, Linux perf와 eBPF 등에 의해 사용됨.

### 2004년: 프레임 포인터 제거

- 2004년에 gcc 개발자 Roger Sayle은 프레임 포인터 생성을 중단하는 변경을 진행함.
- 이 변경은 성능 향상을 가져왔으나, eBPF의 등장으로 오늘날에는 일부 디버거/프로파일러가 이로 인해 문제를 겪음.

### 2005-2023년: 고장난 프로파일러의 겨울

- 프레임 포인터 제거 변경이 x86-64에도 적용되었으나, 이 아키텍처는 더 많은 레지스터를 가지고 있어 큰 이득이 없었음.
- 이로 인해 많은 디버거/프로파일러가 제대로 작동하지 않게 됨.

### 2014년: Java in Flames

- Netflix에 합류했을 때, Java의 프레임 포인터 지원 부족이 모든 애플리케이션 스택을 깨뜨림을 발견함.
- 이 문제를 해결하기 위해 JVM c2 컴파일러에 대한 수정을 개발함.

### 2015-2020년: 오버헤드

- 프레임 포인터를 모든 것에 추가하는 것의 성능 오버헤드는 일반적으로 1% 미만임.
- 특정 마이크로벤치마크에서는 오버헤드가 10%에 달할 수 있음.

### 2022년: 업스트림 시도

- Google, Meta, Netflix 등 대형 기업들이 이미 프레임 포인터를 모든 것에 활성화했음을 암시함.
- 이러한 변경을 모두에게 이익이 되도록 기본값으로 설정하는 데는 여러 어려움이 있음.

### 2023, 2024년: Fedora와 Ubuntu에서 프레임 포인터

- Fedora는 프레임 포인터를 다시 활성화하는 제안을 받아들임.
- Ubuntu도 24.04 LTS 버전에서 기본적으로 프레임 포인터를 활성화함.

### 2034년 이후: 프레임 포인터를 넘어서

- 스택을 추적하는 데는 여러 가지 방법이 있으며, LBR, BTS, AET, DWARF, eBPF 스택 워킹, ORC, SFrames, 그림자 스택 등이 있음.
- 미래에는 SFrames나 그림자 스택이 모든 스택 추적에 사용될 수 있음.

### 결론

- 프레임 포인터의 복귀는 CPU 플레임 그래프를 더욱 의미 있게 만들고, Off-CPU 플레임 그래프를 처음으로 작동시키며, 다른 새로운 가능성을 열어줌.
- 연속 프로파일러에게도 승리이며, 프로파일러가 완전히 작동하기 위해 고객에게 OS 변경을 설득할 필요가 없어짐.

### GN⁺의 의견

- 프레임 포인터의 복귀는 시스템 성능 분석과 디버깅에 큰 도움이 될 것으로 보임. 특히 복잡한 소프트웨어 시스템에서 문제를 진단하고 성능을 최적화하는 데 필수적인 도구임.
- 이러한 변화는 오픈소스 커뮤니티의 협력과 기여의 중요성을 보여줌. Fedora와 Ubuntu의 결정은 다른 배포판에도 영향을 미칠 수 있으며, 이는 전체 리눅스 생태계에 긍정적인 변화를 가져올 것임.
- 프레임 포인터를 다시 도입하는 것은 성능 저하와 디버깅 용이성 사이의 균형을 맞추는 문제임. 이러한 결정은 실제 운영 환경에서의 성능 테스트와 분석을 통해 더 잘 이해될 수 있음.
- 기술적인 배경이 있는 사용자들에게는 이러한 변화가 흥미로울 수 있으며, 시스템 성능 향상에 관심이 있는 개발자나 시스템 관리자들에게 유용한 정보를 제공함.
- 프레임 포인터와 유사한 기능을 제공하는 다른 기술이나 도구가 있다면, 예를 들어 Intel의 VTune Profiler나 AMD의 uProf와 같은 하드웨어 기반 프로파일러를 사용할 수 있음. 이러한 도구들은 프레임 포인터 없이도 성능 분석을 가능하게 함.

## Comments



### Comment 23782

- Author: neo
- Created: 2024-03-18T10:00:12+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=39731824) 
- 2000년대 초반 스택 프레임 포인터 생략이 퍼지기 시작했을 때의 경험
  - 저자는 당시 컴퓨터 과학을 공부하고 있었으며, 사용하는 컴퓨터는 오래되고 성능이 낮았음.
  - 디버깅이 어려워지자 Python을 사용하기 시작함으로써 디버깅 문제를 피함.
- 페도라(Fedora) 배포판에서 스택 프레임 포인터를 유지하기 위한 노력
  - 스택 프레임 포인터가 큰 오버헤드를 가진다는 잘못된 믿음이 있었으나, 실제 오버헤드는 1% 미만임.
- 애플이 ARM 아키텍처에서 스택 트레이스를 항상 의미 있게 유지한 점
  - 특정 함수는 프레임 레코드를 생성하지 않을 수 있지만, 스택 트레이스는 디버그 정보 없이도 유의미함.
- 구글에서의 경험과 커뮤니티와의 20년간의 논쟁
  - libunwind를 gperftools에 적용하기 위한 패치 작업 및 유지보수 경험 공유.
- 과거에 `-fomit-frame-pointer` 옵션으로 성능 향상을 경험한 사례
  - 32비트 프로세서에서 MySQL과 PHP를 컴파일하여 하드웨어 비용 절감.
- Virgil 프로그래밍 언어의 스택 프레임 관리 방법
  - 동적 스택 할당이 없는 경우, 간단한 테이블 조회로 프레임 크기를 찾을 수 있음.
  - 메타데이터 디코딩을 구현하는 코드에 대한 설명.
- 스택을 '걷는' 대신 RBP와 RSP를 사용하여 두 개의 스택을 관리하는 아이디어
  - 호출 스택이 단순히 반환 주소의 배열이 됨으로써 스택 걷기의 필요성 감소.
- 프레임 포인터에 대한 지지와 관련된 경험 및 생각 공유
  - 프레임 포인터 활성화 여부는 사례별로 결정되어야 하며, 벤치마킹이 중요함.
  - 빌드 시스템이 이를 전체적으로 변경할 수 있는 기능을 제공하는 것의 중요성.
  - SFrame에 대한 기대감과 현재 문제를 해결할 잠재력.
- 프로파일링이 20년 동안 문제가 되었고 이제야 해결되었다는 의견
  - 프레임 포인터의 부재가 많은 사람들에게 고통스러웠으며, 이제 리눅스가 그것을 되돌리는 것을 보며 그들의 노력이 인정받는 것 같음.
- 시스템 프로파일링을 가능하게 하는 메커니즘의 성능에 대한 불만이 역설적임
  - 성능 문제를 식별할 수 있게 해주는 시스템에 대한 성능 불만은 성급한 최적화의 극치임.