[Chapter3.5-3.9] 저수준 계층? 메모리라는 사물함에서부터 시작해 보자

[ella-yschoi]

감상평을 남겨주세요! 📝

• 범위: Chapter 3.5-3.9
• 기한: 7/13(토) 오전 11시까지

[yunseorim1116]

이번 파트도 결국 끊임없이 가상 메모리를 추상화하여 물리 메모리를 효율적으로 사용하는 법을 강조하기 위한 빌드업 같다고 느꼈습니다. 프로세스나 스레드, 동기 비동기. 이런 것들을 배울땐 재밌다고 느꼈는데 이번 파트는... 딱히 이렇다할 말이 없었습니다. 중요하지 않은 내용이다? 라는 뜻은 절대 아니고요..... 책 내용이 점점 저의 실제 개발경험과 멀어졌기 때문이지 않을까 싶습니다.

그래서 아쉽습니다. 어떻게 더 공부를 하고 복습하고 적용해야할지.....생각해보아야겠습니다.....! !

정리링크 라도 올립니다.

[ella-yschoi]

저도 읽으면서 실제 개발 경험과 멀어졌다는 느낌을 받았어요.
분명 저수준 계층을 설명하는데, 나에게는 너무 추상화된 것 같은 느낌을 지울 수 없었습니다 허허

[hanana1253]

프론트엔드에서 프로그래밍할 때 실제로 활용할 수 있는 부분이 많진 않았던 것 같긴 해요.. 그냥 교양책읽는 느낌

[ella-yschoi]

감상평

• 위에 서림님이 말씀하신 것처럼 이번 장은 실제 개발 경험과 조금 멀어졌다는 느낌을 받았습니다.
• 저수준 계층을 이해해서 실제 개발에 적용해보고 싶었는데 조금 아쉬웠어요.
• 그래도 최대한 머릿속으로 그림을 그려가며 여러 번 책을 읽어 보았습니다.
• 3.7장처럼 메모리 관련 버그를 방지하거나, 디버깅에 도움이 될 수는 있겠죠?

3.5장: 메모리를 할당할 때 저수준 계층에서 일어나는 일

• 3.5장 초반에 x86 아키텍처에 대해 언급하는데, 마침 지난 스터디 시간 후에 궁금했던 개념이라 반가웠습니다.
• x86에 대해서는 [Chapter3.1-3.4] 스택은 정말 낮은 주소 방향으로만 커지는가? 🤔🤔 #10 로 올려두었습니다.
• 천지인 비유 덕분에 각 단계에 따른 역할 설명을 잘 이해했습니다.
• 그리고 프로세스 → 클라이언트, 운영체제 → 서버, 시스템 콜 → 네트워크 요청 라는 관점도 이해가 쉬웠고요.
• 요약하자면.. 커널 상태 → 모든지 다 할 수 있는 커널 신 👑, 사용자 상태 → 제한이 많은 사용자 나부랭이 🥺
• 이전에 주현님과 CS 스터디를 하면서 System Call에 대해 공부한 적이 있는데, 같이 보면 좋을 것 같아 그 중 일부를 아래에 공유합니당

참고(1) System Call이란?

• 사용자 프로그램이 운영체제의 서비스를 받기 위해 Kernel 함수를 호출하는 것
• 만약 I/O(Input/Output: 읽고 쓰는 작업)를 하고 싶은데 운영체제만이 할 수 있는 상황이라면, 스스로 Interrupt를 거는 것
  → System Call
• CPU를 운영체제에 넘기려 할 때 직접 PC(Program Counter)를 넘길 수 없기에, 프로그램이 자신의 기계어를 통해 Interrupt line 세팅
  → Interrupt 발생 (여기서는 Software Interrupt)

참고(2) System Call의 원리

• CPU가 I/O를 요청하는 명령어는 전부 특권 명령어로 묶여 있음
  • 즉, 사용자 프로그램이 직접 실행할 수 없음
  • mode bit이 사용자 모드(1) 일 때는 특권 명령을 수행할 수 없기 때문
• 따라서 운영체제에게 대신 해 달라고 요청(System Call) 필요
  • 사용자 프로그램 위치에서 기계어 실행되다가 → 운영체제에게 CPU 사용권을 넘김
  • 이때, 기계어가 실행되는 점프 발생 (프로그램의 가상 메모리를 가로질러 점프)

3.6장: 고성능 서버의 메모리 풀은 어떻게 구현될까?

• 메모리 풀의 존재 이유는 기존 문제로부터 기억하면 좋군요. malloc으로 메모리 할당과 해제가 너무 빈번하면 성능에 영향을 끼치기 때문!
• 그래서 성능에 영향을 끼치지 않도록 메모리 풀은 아래와 같은 특징을 가지고 있습니다.
• 특정 상황에서만 높은 성능을 발휘한다. (다른 상황에서 사용이 불가) → 즉, 선택과 집중이랄까?
• 자체적으로 메모리 할당과 해제를 관리하는 방식을 가지고 있다. 우회한다. → 난 성능이 구린 표준 라이브러리와는 달라!
• 특정 사용 패턴에 따라 추가 최적화도 할 수 있다.
• 메모리를 요청하는 것만 가능하고 해제는 처리하지 않는다. 사용자 요청 처리가 모두 완료되는 시점에 한꺼번에 해제한다. → 효율의 끝판왕
• 메모리가 부족할 때 요청하는 새로운 메모리 조각은 이전 메모리 조각의 두 배여야만 한다. → 귀찮으니까 두 개 같이 줘라
• 정리하자면, 메모리 풀은 메모리 할당과 해제에 따른 부담을 최소화 하여, 성능을 극대화한다!

참고(3) 메모리 풀 vs. 범용 메모리의 차이

책 설명이 눈에 잘 안 들어와서 아래와 같이 표로 정리해 보았습니다.

	메모리 풀	범용 메모리 할당자
위치	응용 프로그램의 일부	표준 라이브러리의 일부
구현	비교적 덜 복잡	비교적 복잡
대상	특정 상황에서만 적용 가능	범용적으로 사용 가능
범용성	매우 떨어짐	넓은 편

3.7장: 대표적인 메모리 관련 버그

• 책에서는 C언어로 예시를 들었지만, JavaScript에서도 몇 가지 메모리 관련 버그가 있을 것 같아요.
• 전역 변수가 프로그램이 종료될 때까지 메모리를 점유해 메모리 누수되는 경우
• 클로서 사용 시, 필요하지 않은 변수까지 유지해 메모리가 누수되는 경우
• 이벤트 리스너를 추가하고 제거하지 않는 경우
• 삭제된 객체 혹은 해제된 메모리을 참조하는 경우
• 객체가 서로를 참조하고 있어 GC가 이를 해제하지 못하는 경우

3.8장: 왜 SSD는 메모리로 사용할 수 없을까?

참고(4) RAM과 SSD의 차이

SSD가 메모리가 될 수 없는 이유는 RAM과 SSD의 차이로 이해해도 좋을 것 같아 표로 정리해 보았습니다.

특성	RAM	SSD
기술/구조적 차이	휘발성 메모리 (DRAM, SRAM)	비휘발성 메모리 (NAND 플래시 메모리)
속도	매우 빠름 (나노초(ns) 단위)	빠름 (마이크로초(μs) 단위), 하지만 RAM보다는 느림
지연 시간	매우 낮음	높음
주소 지정 단위	바이트, 각 바이트마다 메모리 주소 부여	조각 단위로 데이터 관리, CPU가 특정 바이트 단위 주소 지정 불가
내구성 및 수명	지속적인 읽기/쓰기에 내구성 있음	쓰기 횟수에 제한이 있어 수명이 짧아질 수 있음
목적	프로그램 실행 중 데이터를 임시로 저장하고 빠르게 접근함	운영체제, 응용 프로그램, 파일 등을 영구적으로 저장함
휘발성/비휘발성	휘발성 (전원이 꺼지면 데이터 사라짐)	비휘발성 (전원이 꺼져도 데이터 유지)

[ddongule]

우와 정리 대박 일단 읽기전에 따봉드립니다 👍👍👍👍👍👍

[iborymagic]

클로서.. 클로써..

[ddongule]

감상평

메모리... 중요한 건 알겠는데 굉장히 복잡하고 이해가 쉽지 않았따. 어따.. 쓴다는건지.. 나원..참..
아무래도 내가 직접 제어하는 영역이 아니다보니 글자가 머리위로 둥둥 떠다닌 것 같다.
다같이 재미지게 이야기 나누면서 정리해봐야 할 것 같다 아무래두.
2장도 다 정리 못했는데 으악!!! 화이팅..

[iborymagic]

• 요번 챕터를 읽으면서, 메모리가 알고보면 관리하기 굉장히 까다로운 존재라는 것을 알 수 있었읍니다..

• 그것과 동시에, 3.7 챕터를 읽으면서 저는 자바스크립트로 굉장히 편하게 코딩을 하고 있었다는 것도 깨달았읍니다.. 브랜든 아이크 아저씨에게 감사를..

• 세그멘테이션 오류, 페이지 누락 오류 등 유명하다고 하는데.. 저는 처음 들어봤읍니다.. 허허..

• 세그멘테이션 오류: 프로그램이 허용되지 않은 메모리 영역에 접근을 시도하거나, 허용되지 않은 방법으로 메모리 영역에 접근을 시도할 경우 발생한다. (ex: 읽기 전용 영역에 어떤 내용을 쓰려고 시도하거나, 운영 체제에서 사용하는 영역에 다른 내용을 덮어쓰려 하는 경우)

  • 세그멘테이션은 운영 체제에서 사용하는 메모리 관리 및 보호의 한 기법이라고 합니다. 지금은 거의 페이징으로 대체됐다고 하네요.
  • 출처: 위키피디아

• 페이지 누락 오류: 프로세스가 접근하려는 메모리 페이지가 물리적 메모리(RAM)에 존재하지 않을 때 발생하는 이벤트입니다. 페이지 폴트는 가상 메모리 시스템의 중요한 부분으로, 메모리 관리와 자원 할당에 있어 핵심적인 역할을 합니다.

  • 출처: 김건우씨의 블로그

[chloe-codes1]

감상평

• 메모리가 할당되는 과정을 low level까지 살펴볼 수 있어서 좋았고, 그걸 직접 관여하지 않아도 된다는 사실에 감사했다 (JVM 고마워..)
• 위의 현철님처럼 Segmentation Fault 와 Page Fault 에 대해서 잘 몰랐어서 이 부분을 추가로 찾아보았다

Segmentation Fault

설명

• 프로그램이 운영 체제로부터 배정받지 못한 메모리 영역에 접근하려고 할 때 발생하는 오류
• 운영 체제 수준에서 메모리 침범을 막는 기능의 일부로, 프로그램이 허용되지 않은 메모리 영역이나 방법으로 메모리에 접근하려고 할 때 발생함

원인

• NULL 또는 할당되지 않은 메모리 영역에 접근
  • 프로그램이 NULL 포인터를 통해서 메모리에 접근하려고 할 때 발생
  • e.g. malloc을 사용하여 메모리를 할당받은 후, 그 메모리가 이미 해제되었거나 올바르게 할당되지 않았음을 감지하지 않고 접근하려고 할 때 발생
• 할당받은 메모리 공간을 벗어난 접근
  • 프로그램이 메모리 할당량을 초과하여 메모리에 접근하려고 할 때 발생
  • e.g. 배열의 인덱스를 잘못 지정하여 배열의 범위를 벗어나는 위치에 접근하려고 할 때 발생

Page Fault

설명

• 프로세스가 접근하려는 페이지가 현재 메인 메모리(RAM)에 없는 경우 발생
• 페이지 폴트가 발생하면 운영 체제는 필요한 페이지를 디스크에서 메모리로 불러와야 하며, 이 과정은 일정 시간이 소요됨

원인

• 페이지 미할당(Unallocated Page)
  • 접근하려는 메모리 페이지가 아직 할당되지 않은 경우
• 페이지 교체(Page Swapping)
  • 접근하려는 메모리 페이지가 현재 디스크에 저장되어 있고 메모리에 없는 경우
  • 주로 메모리 부족으로 인해 덜 사용된 페이지를 디스크로 내보낸 후 발생함
• 권한 오류(Protection Fault)
  • 프로세스가 접근하려는 페이지에 대해 적절한 접근 권한이 없는 경우

[hanana1253]

감사가 넘치는 스터디..

[sunhpark42]

오랜만의 메모리 뜯어보기! 앞장보다는 읽는 시간이 좀 걸렸지만, 그래도 재밌게 잘 읽었다.

메모리 관리.. 안해도 되게 만들어준 고수준언어환경 땡큐...

[thgr8ganzi]

감상평

• 처음에 3-57 그림보고 L1/L2/L3 캐시메모리 그림 인줄 알았다.
• 유저모드 커널모드만 알고있었는데 RIng2, Ring1 level은 책을 읽고 처음봤다.
• 스레드 safe 를 위해서 thread local storage 를 유용하게 쓸수있다는 지식을 얻고가서 좋다

[hanana1253]

감상평: malloc과 친해진 느낌. 커널 모드와 사용자 모드가 어떻게 다른지 조금 더 잘 알게 되었다. 영화 같은 곳에서 충분히 알지 못하고 성숙하지 못한 자가 많은 힘을 가지면 위험하다는 그런 교훈이 와닿는 천지인 비유였다.
메모리는 가상 가상 가상!!
벌써 절반 했다. 뿌듯

3.5

p.256
실제로 할당한 메모리가 사용되는 순간에 물리 메모리를 할당하게 됩니다 ... malloc은 메모리의 2차 할당에 불과하며, 할당받는 것도 그나마 가상 메모리에 불과합니다. 그리고 이 과정은 모두 사용자 상태에서 처리됩니다.

p.257
malloc이 brk를 호출하면 커널 상태로 전환되는데, 이때 운영 체제의 가상 메모리 시스템이 힙 영역을 확장하는 작업을 시작합니다.

커널 상태로 전환된다고? 아하 물리 메모리 부분은 아직 처리 안했다는 뜻이고 brk 호출의 경우는 여유 메모리를 찾지 못한 경우를 말한거구나? ㅇㅋㅇㅋ

malloc이 메모리를 할당하고 해제하는 과정에서 왜 성능 영향이 있는지 알게 되었다. 수면 밑 백조의 다리처럼 천지인을 오가며 열심히 움직이고 있었구나.

3.6

p.262 새로운 메모리 조각의 크기는 항상 이전 메모리 조각의 두 배... 메모리 풀은 malloc이 반환한 메모리 위에 재할당되는 것을 알 수 있다.

알쏭달쏭

p.264 스레드 전용 저장소를 사용하면 매우 흥미로운 문제가 하나 발생합니다. 스레드 A가 메모리 조각을 요청했지만 그 수명 주기가 스레드 A 자체를 넘어서는 상황을 가정해 봅시다... 이 질문은 여러분 몫으로 남겨 두겠습니다.

뭐야 어서 알려줘요

3.7

오늘은 새롭게 중간 챕터인 3.7을 스킵해볼까?

3.8

맨날 컴퓨터 살 때 SSD 말로만 들었는데 조금 더 친근해진 느낌
그러나 여전히 32비트 시스템, 64비트 시스템 차이에 대해서 잘은 모르겠다.

3.9

엄청 짧네. 호스트 할거라면 여기 걸렸으면 좋겠다.

https://teal-line-f3e.notion.site/CH-03-d845a33306c6473fbe585df77f1e194a?pvs=4

[hanana1253]

물리 메모리와 가상 메모리가 ... 플라톤의 이데아 이론을 연상시켰다 (전혀 연관없음)

[sa02045]

• 이번 주는 짧아서 부담없었습니다…(사실 바빠서 자세하게 못읽었음...)
• 예전에 시스템 프로그래밍 강의들었던 기억이 새록새록 났다.
• 커널 상태 - 사용자 상태를 구분하기
• 실제 메모리 신경쓰지 않기, 아예 신경끄기(malloc도 가상 메모리를 할당하는 것)
• 자바스크립트에서 메모리를 관리하지 않으니 몰랐던 내용을 배울 수 있었음
• 메모리 관련 버그와 메모리 누수 개념에 대해 다시 읽었음
  • 이러한 메모리 버그를 컴파일타임에 잡을 수 있는 러스트 장점 다시 생각함
  • C언어에서 메모리를 직접 다루지 않아도 애플리케이션 레벨의 JS, 프론트에서도 충분히 메모리 누수가 발생할 수 있음. 그 밑바닥에서는 어떻게 메모리 누수가 발생하는지 추측할 수 있었음

 useEffect(() => {
    const handleResize = () => {
      console.log('Window resized');
    };

    window.addEventListener('resize', handleResize);

    return () => {
      // 반드시 같은 참조값을 가지는 함수 handleResize로 removeEventListener로 해제해줘야함
      // JS 내부 엔진에서는 함수의 메모리 주소값을 활용해서 해제하지 않을까?
      window.removeEventListener('resize', handleResize);
    };
  }, []);

chatGPT가 정리해준 JS, 프론트 메모리 누수

• 이벤트 리스너 미제거: 이벤트 리스너를 등록하고 나서 제거하지 않으면, 해당 리스너가 계속해서 참조를 유지하게 되어 메모리가 해제되지 않는 문제가 발생할 수 있습니다.

• 클로저(Closure): 클로저는 함수가 선언될 당시의 스코프를 기억하는 기능을 말합니다. 클로저를 잘못 사용하면, 필요하지 않은 변수들을 계속해서 메모리에 유지하게 되어 메모리 누수가 발생할 수 있습니다.

• 전역 변수: 전역 변수를 많이 사용하면, 필요하지 않은 변수들이 메모리에 계속 남아 있게 되어 메모리 누수가 발생할 수 있습니다.

• 타이머와 콜백: setInterval이나 setTimeout을 사용한 후, 이를 명시적으로 해제하지 않으면 메모리 누수가 발생할 수 있습니다. 타이머가 계속해서 참조를 유지하기 때문입니다.

• DOM 참조 보관: 자바스크립트 객체가 DOM 요소를 참조하고 있을 때, 해당 DOM 요소가 삭제되더라도 자바스크립트 객체가 이를 참조하고 있으면 메모리 누수가 발생할 수 있습니다.

• 잊혀진 객체: 코드 상에서 객체를 생성하고 나서 이를 참조하지 않으면, 가비지 컬렉터가 이를 해제할 수 없습니다. 이는 특히 객체가 다른 객체의 속성으로 저장되어 있을 때 자주 발생합니다.-