Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[item6] 요즘 JVM의 가비지 컬렉터는 상당히 잘 최적화되어서 가벼운 객체용을 다룰때는 직접 만든 객체 풀보다 훨씬 빠르다? #7

Open
KimJeongHoon3 opened this issue Feb 10, 2023 · 9 comments

Comments

@KimJeongHoon3
Copy link
Collaborator

p34 아래쪽부분에 자체 객체 풀을 만드는것을 조심해야한다며, 요즘 JVM 가비지 컬렉터가 뭔가 객체 풀 역할을 잘 해준다는 이야기 같은데.. 개인적으로 GC가 안쓰는 객체를 처리한다고만 알고있어서 그런지, 해당 구절이 잘 이해가 안되네요~
GC 관련해서 잘 아시는분 계시면 기깔난 설명 부탁드려요 ㅎㅎ 혹은 간단하게나마 같이 공부하면 어떨까 싶어서 질문올려요!

요즘 JVM의 가비지 컬렉터는 상당히 잘 최적화되어서 가벼운 객체용을 다룰때는 직접 만든 객체 풀보다 훨씬 빠르다

@HwangSeonHo
Copy link
Collaborator

아직 못 봤는데 최근에 gc글 올라온 거 있어서 혹시나 하고 공유합니다!
https://whatsup.nhnent.com/shortCut/boardArticle/323201

@pjhsk113
Copy link
Collaborator

pjhsk113 commented Feb 12, 2023

GC가 객체 풀 역할을 해주는 것이 아니고
데이터베이스 커넥션처럼 객체 생성 비용이 아주 비싼 경우가 아니라면,
일반적으로 객체를 생성하고 GC되는 과정의 비용이 더 적다는 것을 나타내는 것 같습니다.(GC 최적화가 잘 되어있기 때문에)

이번 item의 주제는 불필요한 객체 생성을 피하자 입니다.
객체 생성을 하지 말라는 것이 아니라 불필요한 객체 생성을 하지말라는 것이기 때문에 단순히 객체 생성을 피하기 위해 직접 객체 풀을 만들어 객체를 재사용하지 말라는 의미로 이해했습니다.

즉, 가벼운 객체를 다루는 직접 만든 객체 pool의 비용 > GC의 비용
을 나타내는 문구인 듯 싶습니다.

@makga87
Copy link
Collaborator

makga87 commented Feb 12, 2023

장호님 답변처럼 객체 풀 역할을 해주는 것으로 보이진 않습니다.

위 문구에 대한 내용을 자세히 따져보아 의문점을 달아보면 다음과 같을 것 같습니다.

  • 예전에는 가벼운 객체도 GC대신 직접 풀을 만들어 사용했었나? 예전 GC가 어땠길래 그러는 것인가?

개인 스터디 브랜치 내용 몇 가지를 공유 합니다.

  1. 객체 풀은 보통 어떻게 만들고, 무슨 기능들이 들어가나?
  • 객체 풀을 만들 때에는, create만 하지 않고, 사용되지 않거나, 특정 조건에 따라, remove도 시킴 (생명주기를 직접 관리하기도 함)
  1. 기존 GC는 느렸었나?
  • 이펙티브 자바 초판이 2003년도다, 나무 위키로 JDK 버전별 연도를 봤을 때, 1.5버전이 2004년 9월 발표 되었으니, 책의 저자는 적어도 1.4 버전을 기준으로도 요즘 GC라 말을 했을 것이라 생각된다.
  • JDK 1.4버전의 GC는 명확히 찾긴 어렵지만, 검색 중, 오라클 홈페이지가 나왔고, JAVA SE 5, 6에서는 default GC가 Serial GC라는 것을 찾았다. (다른 GC를 선택 가능한지는 안해봐서 모르겠다) (https://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html)
  • 이는, 1.4 이하 버전은 Serial GC가 기본 GC일수 있고, 더 낙후된 GC일수도 있다.
  • 첨언 : SerialGC는 JDK 18에서도 지속적으로 개선되고 있다.(모든 GC들은 계속 개선을 시키는 것으로 보임)
  • 저자가 경험한 JDK에서는 많이 낙후된 우리가 모르는 GC 혹은 최적화 이전 Serial GC를 경험했을 것으로 판단된다.
  • Serial GC는, 싱글 스레드로 동작하고, 객체의 갯수와 크기가 많아지면 많아질수록, 싱글스레드가 해야할 작업이 많아진다는 것을 의미한다. (각 객체의 사용 상황도 확인해봐야 할 것이므로...)
  • 이는, 무분별하게 새로운 생성자를 많이 생성하면 생성할 수록, GC 동작시간은 점점 느려진다.
  • 그러므로, 사용자가 해당 GC를 사용하는 경우, 직접 pool을 생성하여, 객체 수나, 생성 및 GC 대상으로 만드는 시점을(객체 = null 등으로) 직접 관리하는 편이 빠르지 않았을까

@KimJeongHoon3
Copy link
Collaborator Author

KimJeongHoon3 commented Feb 13, 2023

@makga87 @pjhsk113 답변 감사합니다!!

다시보니, 이펙자바에서 이야기한 내용이 가벼운객체의 경우 자체적으로 만든 객체풀을 사용할경우 풀로 반납의 비용보다 GC가 수거해가는 비용이 더 적다는 것을 이야기하는것 같네요~ (GC가 최적화가 잘 되어있기때문에)
풀을 사용하게되면, 객체의 자원해제시 재사용을 위해서 여러 조치들이 필요할것인데 (ex. 해당 객체에 대한 자원 초기화, 임계영역처리 등을 위한 락 사용 등) 이런 부분들을 처리하기위해 그냥 GC에서 수거하는것보다 더 많은 비용이 드는것에 대한 이야기가 아닐까 싶네요~

장호님이 답변주신 내용으로는 pool로 객체생성하는 비용이 GC의 비용보다 비싸다고 말씀해주신것 같아서, 관련해서 생각해보았는데, pool은 어차피 보통 생성이 필요할떄 갯수에 맞춰서 생성되거나 초기에 쭉 생성되기떄문에, 객체수거시 지속적으로 발생하는 GC비용과 비교하는건 좀 어렵지 않을까 생각도 되었습니다~(제가 잘못 이해했다면 말씀주세요ㅠㅎㅎ)

@pjhsk113
Copy link
Collaborator

@makga87
학습하신 내용 공유 감사합니다!👍
그런데 저희가 읽고있는 이펙티브 자바는 Java7, 8, 9 기준으로 쓰여진 개정판이라
Paralell GC와 G1GC 기준으로 요즘 GC라고 표현한게 아닌가요!?!

@KimJeongHoon3
정훈님이 말씀하신 내용에 동의하고 있습니다~!
그런데 제가 말씀드린건 pool로 객체 생성하는 비용이라기 보다는
가벼운 객체를 다루는 직접 만든 객체 pool을 사용하는 전체의 비용이 더 비싸다는 의미였습니다!!

객체를 생성해 메모리에 올려두는비용 + 이용과 반납의 비용 > GC 비용

@KimJeongHoon3
Copy link
Collaborator Author

@pjhsk113 아하 결국 같은말이네요 ㅋㅋ 감사합니다~~!

@makga87
Copy link
Collaborator

makga87 commented Feb 13, 2023

@pjhsk113

해당 글귀가 개정판 이후에 적힌 글귀인지 확인이 필요하겠네요.

그리고, 7,8,9 버전인경우에도 마찬가지 아닐까요? 과거 가벼운 객체역시 풀을 사용하던 시절은 결국, 개선된 GC를 사용하기 전이고요,
Paraller GC, G1GC를 요즘 기준이라 표현해도, 그 이전 GC는 결국 Serial GC 이잖아요?

결국 싱글스레드로 GC처리 할 때 발생하는 문제로 귀결되는건 마찬가지로 보여집니다

@makga87
Copy link
Collaborator

makga87 commented Feb 13, 2023

[추가]

  • G1GC의 첫 소개는 JDK 1.6 부터 였다네요, 정식 릴리즈는 아니었을테니, 아마 과거엔 Serial, Paraller, CMS 정도가 메인이 되었을거라 추측이 되는데, 해당 GC들 사용 시, 객체 갯수에 따라 GC 성능에 대한 지표 같은 참고자료가 있음 좋겠네요
  • 제 답변이 너무 Serial GC에만 매몰되어져 있어, 수정합니다.

@KimJeongHoon3
Copy link
Collaborator Author

stop the world는 minor, major 모두 일어나는가?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants