참고)

아래에 서술할 내용은 벤치마크 점수나 게임 성능과는 상관이 없다 (벤치마크나 게임은 보통 NDK를 통해 네이티브로 구동된다)

안드로이드가 아이폰한테 벤치마크, 게임 성능이 발리는 건 OS 탓이 아니라 그냥 칩셋이 구려서 그런 거다





Garbage Collector (쓰레기 수집기)



1. 애플의 ARC vs 안드로이드의 GC


애플 플랫폼과 안드로이드는 메모리 관리 기법에서 차이가 있다. 애플은 ARC라고 하는 레퍼런스 카운팅 방식을 쓰며 안드로이드는 GC를 사용한다. 복잡한 설명은 버리고 요약하자면


- ARC: 필요한 메모리를 할당해서 쓴 다음, 필요 없어지면 그때그때 바로 시스템에 반환하는 방식

- GC: 다 쓴 다음에도 바로 반환하지 않고 냅둬놓고 나중에 GC(쓰레기 수집기)가 알아서 찾아서 반환하도록 하는 방식


따라서 ARC는 메모리가 언제 해제되는지 결정론적으로 정해져 있다. 반면 GC는 메모리가 언제 해제되는지 아무도 모른다


GC는 메모리 관리에 대해 전혀 신경 쓰지 않아도 되므로 개발자 입장에서 약간 더 편하다. (사실 깊게 파보면 꼭 그렇지도 않지만 어쨌든 초보 개발자 입장에선 편한다) 그러나 그 대신 잃는 게 많다




2. Stop-the-world


GC 방식은 쓰레기 수집기가 쓰레기(다 쓴 메모리)를 한꺼번에 청소하는 방식이다. 근데 청소를 하려면 일단 어떤 게 쓰레기(다 쓴 메모리)인지를 알아야 한다


그리고 그러기 위해서는 주기적으로 프로그램을 멈춰서 검사해야 한다 (stop-the-world)


당연하지만 그때마다 사용자는 환상적인 좆같음을 느낄 수 있다. 안드로이드 초기의 달빅 VM에서 이러한 문제가 굉장히 심각했다.


물론 구글이 바보는 아니라서 안드로이드 버전업을 거치며 GC의 알고리즘을 개선해나갔고 그 결과 지금은 예전만큼 심각하지는 않다

(지금도 stop-the-world 문제에서 자유로운 건 아니다. 어디까지나 많이 완화됐을 뿐)


그러나 그 개선된 GC에는 트레이드오프가 있다. 매우 복잡한 알고리즘으로 최적화를 하는데, 그 결과 배터리 소모가 심해졌다




3. 메모리 사용량


또한 GC 방식은 쾌적하게 동작하기 위해서 매우 많은 메모리를 필요로 한다. ARC와 GC를 비교해서 알아보자


ARC로 만든 프로그램과 GC로 만든 프로그램이 있다고 하자. 그리고 두 프로그램 각각의 메모리 최소 요구 용량이 1GB라고 하자


- ARC 기반 프로그램은 메모리 1GB짜리 컴퓨터에서 실행시키든, 메모리 2GB짜리 컴퓨터에서 실행시키든 똑같이 잘 돌아가고 비슷한 성능으로 실행된다

- 하지만 GC 기반 프로그램은 그렇지 않다. 메모리 1GB짜리 컴퓨터에서는 랙이 자주 걸리며, 훨씬 더 큰 용량의 메모리를 탑재한 컴퓨터에서 돌려야 괜찮게 돌아간다


왜 이런 차이가 발생하는가?


ARC는 그때그때 사용한 메모리를 바로 반환하므로 효율적이고 결정론적(메모리 해제 시점이 정해져 있음 = 특정 시점에 사용하는 메모리 용량이 정해져 있음)이다. ARC 기반 프로그램에서 100MB짜리 연산을 3번 한다면 최대 메모리 사용량은 100MB다 (100MB 할당 - 해제를 반복하므로)


반면 GC는 메모리를 일단 사용해놓고 뒷처리는 쓰레기 수집기에게 짬처리한다. GC 기반 프로그램에서 100MB짜리 연산을 3번 한다면 메모리 사용량은 최대 300MB까지도 오를 수 있다. (GC가 호출되기 전에 3번 연속 할당) 그런데 만약 컴퓨터에 탑재된 메모리가 100MB밖에 안 된다면? 메모리 부족으로 튕기지 않으려면 매 연산을 마친 후 GC가 호출돼야 한다. 즉 메모리 용량이 충분히 크지 않다면 GC를 더 자주 호출해야 하고 이게 프로그램의 성능 저하로 이어진다



아래는 실제 벤치마크 결과이다

(https://cse.buffalo.edu/~mhertz/gcmalloc-oopsla-2005.pdf)



2aaf9e36ebd518986abce895448373657e82


각 그래프에서 맨아래에 겹쳐져 있는 두 개의 y=1 선(Lea)이 (ARC는 아니지만 ARC와 같은 결정론적 특징을 가진) C언어의 메모리 할당자이고 그 외 다른 선들이 GC 알고리즘

X축은 (최소요구량 대비) 메모리 용량이고 Y축은 GC에 소요된 시간




2aaf8268f5dc3f8650bbd58b36827769fe27fb


X축은 가용 메모리 용량, Y축은 프로그램 실행 완료에 걸린 시간



위 그래프들이 의미하는 바는 GC 기반 프로그램을 그럭저럭 쾌적하게 돌리기 위해서는 수동 메모리 관리 기법 대비 5~6배 이상 많은 메모리가 필요하다는 것이다. 그야말로 그냥 메모리 잡아먹는 괴물이다


_213_javac를 보면 메모리 용량 36MB 환경에서 Lea 명시적 할당자는 프로그램 실행 완료에 14초가 걸리지만 GenMS GC는 211초나 걸린다





4. 애플의 선택


1990년대부터 지금까지 자바, 파이썬, 루비, 자바스크립트 등 수많은 언어가 GC를 사용하고 있다


애플도 본래 맥OS에서 일부분 GC를 지원하고 있었으나 iOS에는 넣지 않았으며 맥OS에서의 GC도 2012년에 완전히 들어내버렸다. 아래는 2011년 개발자 컨퍼런스에서 애플이 한 말이다


[ 우리는 GC를 iOS에 가져오지 않을 것입니다. 유감스럽게도 GC는 성능에 영향을 미칩니다. 쓰레기는 애플리케이션에서 축적되어 메모리 사용량을 증가시킬 수 있습니다. 또한 GC가 비결정적으로 동작하기에 CPU 사용량이 매우 높고 버벅임이 생기게 됩니다. 그것이 모바일 플랫폼에서 GC를 사용하지 않은 이유입니다. GC에 비해 수동 메모리 관리는 학습하기 어렵고 골치 아픈 일입니다. 하지만 더 낫고 예측 가능한 성능을 제공합니다. 그래서 우리는 이것을 메모리 관리 전략의 기본으로 선택했습니다. 실제 환경에서는 고성능과 버벅임 없는 사용자 경험이 유저들에게 중요하기 때문입니다 ]


[ At the top of your wishlist of things we could do for you is bringing garbage collection to iOS. And that is exactly what we are not going to do… Unfortunately garbage collection has a suboptimal impact on performance. Garbage can build up in your applications and increase the high water mark of your memory usage. And the collector tends to kick in at undeterministic times which can lead to very high CPU usage and stutters in the user experience. And that’s why GC has not been acceptable to us on our mobile platforms. In comparison, manual memory management with retain/release is harder to learn, and quite frankly it’s a bit of a pain in the ass. But it produces better and more predictable performance, and that’s why we have chosen it as the basis of our memory management strategy. Because out there in the real world, high performance and stutter-free user experiences are what matters to our users. ~Session 300, Developer Tools Kickoff, 2011, 00:47:49 ]



즉 애플은 사용자 경험을 중요시하여 GC 대신 ARC를 사용했다. 반면 구글은 당장 약간의 개발자의 편의(= 낮은 앱 개발 진입장벽)를 위해 GC를 사용하는 자바를 안드로이드에 채택했다


그 선택의 차이가 사용자 경험에 있어서 iOS와 안드로이드의 근본적인 차이를 만들었다