[TroubleShooting] sbt could not find or load main class file

Have you gotten this error message, when you execute sbt in git bash?

Error: Could not find or load main class file
Caused by: java.lang.ClassNotFoundException: file

But the problem is that it works in Windows CMD, but it doesn't work only git bash

So I tried to find solution in google, and I got a solution like this
In short, Change the path that "C:\Program Files" to "C:\Progra~1" and "C:\Program File(x86)" to "C:\Progra~2". because git shell can't recognize space and special character such as () in path.

So I generated environment varaibles like below

And I changed SBT and Git path to the variables.

But It still doesn't work

So I found another way and I did it.(another way)

In short, you should execute sbt.bat not sbt

It works fine!

But typing sbt.bat is so annoying, I wanted to type only "sbt"

So I set alias in git bash like below

$> vi ~/.bashrc

Add "alias sbt 'sbt.bat'" in .bashrc

Apply the script

$> source ~/.bashrc

Now, It works even if you type "sbt"

[TroubleShooting] git bash에서 sbt로 프로젝트 생성이 안되는 증상

Error 내용은 다음과 같다

Error: Could not find or load main class file
Caused by: java.lang.ClassNotFoundException: file

그러나 윈도우 기본 터미널인 cmd에서는 잘 동작한다.

Git bash에서 할 수 있는 방법을 찾던 중, 구글링 결과 다음과 같은 해결책을 제시해주었다.(링크)
요점은, 일반적으로 윈도우에서 인스톨시 C:\Program Files나 C:\Program Files(x86)에 인스톨하는데 여기 띄어쓰기와 괄호가 문제라는 것이다. 그래서 이를 C:\Progra~1, C:\Progra~2로 바꾸라는 것이다.

그래서 시키는데로 했다. 먼저 두 환경 변수를 만들고,

Path에 sbt를 저 환경변수로 바꿔주었다

그러나 여전히 똑같은 에러가 난다...

다른 방법을 찾아 헤매다가 다음을 발견했다.(링크)

요점은 windows에서는 sbt가 아니고 sbt.bat를 실행하라는 것이다.

잘 동작한다!

매번 sbt.bat를 치는건 귀찮으니, git bash의 alias를 추가하기로 한다.
$> vi ~/.bashrc

alias sbt 'sbt.bat'를 추가한다.

$> source ~/.bashrc를 통해 적용한다.

이제 sbt로도 잘 동작한다!

[English] 개발 관련 강의에서 나오는 단어/표현

A

Abbreviation 축약, 축약형

Anticipated
기대하던, 대망의
confer) anticipate : 기대하다, 예상하다, 예측하다

Arguably
주장하건데, 거의 틀림없이

Assemble
모이다, 집합시키다, 조립하다

Associative연합의, (수학에서) 결합법칙이 되는 상황을 이를 때( a * (b * c) = (a * b) * c )
confer) 결합법칙 : associated law

Assure
장담하다, 확인하다, 보장하다

Auxiliary

조동사의, 예비의

Awkward
어색한, 불편한, 곤란한

B

C

Catenation
연쇄

Coalesce
(큰 덩어리로) 합치다
confer) coalesce into : ~으로 합동하다

coefficient계수

cohesive
화합하는

complement보완하다, 덧붙이다, (필요한) 전체량
confer) compliment : 칭찬하다

consecutive
연이은, 연달아

concise간결한, 축약된

conform

따르다, 순응하다, ~에 일치하다.

confound 어리둥절하게 하다.
Example) I'm a bit confounded by the difference Unit, Nil, Null and Nothing

cornerstone초석

conjunction
접속사, 결합, &&(Double ampersand)

consequence 결과, 중요함

constituent주민, 구성 성분, ~을 구성하는

constrain~하게 만들다, ~하는 것을 제한하다.

converge 

수렴하다, 모여들다

conversely정반대로, 역으로

convince납득시키다, 확신시키다, 설득시키다
confer) convince somebody of ~

covariant
공변하는
confer) contravariant : 반변하는
confer) contra : 반대로
*) Generic을 사용하는 객체지향 언어에서 Covariant와 Contravariant가 의미하는 바는 다음과 같다.
Type A의 subtype B가 존재하고, Generic을 사용하는 Type C가 존재할 때(scala - C[T], java - C<T>) C[A](C<A>)가 C[B](C<B>)의 subtype으로 간주되면 covariant하다고 하며, 반대로 C[B](C<B>)가 C[A](C<A>)의 subtype으로 간주되면 contravariant하다고 한다.

Crucial
중대한, 결정적인

Cumbersome
크고 무거운, 다루기 힘든, 번거로운, 길고 복잡한

D

Damping 
제동하는, 진폭을 감소시키는

Deduce 
추론하다
confer) Deduction : 추론, 연역, 공제

Denote 조짐을 알려주다, 의미하다

Detract 손상시키다. 폄훼하다
Example) Changing the value would detract from the theory of.

Detour우회하다, 우회로, (방향, 분위기) 전환, 환기

Disjunction
괴리, 분리, ||(Double pipe)

E

Elsewhere
(어딘가) 다른 곳에서

Exotic
이국적인, 외국의

F

Far-reaching
지대한 영향을 가져올, 원대한

G

govern통치하다, 지배하다, 좌우하다

Go wrong
실수하다, 잘못되다, 고장나다, 문제를 겪다, 문제가 있다

H

Homogeneous동종의

I

Ignorant
무식한, 무지한, 무지막지한

Implication
영향, 함축, 암시, 연루

Interoperability
상호 호환성

In that sense 그러한 면에서, 

J
K
L

Leave out
빼다, 생략하다

Leaning
성향, (한 쪽으로)기운

Lexical

어휘의

M

Machinery
기계, 기계 부속품, 기구, 조직, 시스템

Merely
주로, 단지, 한낱

Merit가치, 훌륭함, 장점, 우수한 평점
confer) Merit system : 실적제
confer) Merit rating : 인사고과

Mess지저분한 상태 또는 사람, 지저분하게 하다
confer) Mess up : 엉망진창으로 만들다

Mourn
애도하다, 애석해하다

N

Namely즉, 다시말해

Negation

정반대, 부정

Noteworthy 주목할만한

O

Occasional
가끔의

Occurrence 발생, 발생하는 것

One-liner
짤막한 농담

P

Perspective 관점, 시각, 균형감, 원근법, 전망

Pervasive
만연하는, 스며드는

Pinpoint
(위치 등을)정확히 찾아내다, 정확히 기술하다, 정확한

Planar 평면의

Polynomial 다항의example) Polynomial expression 다항식

Ponder 곰곰이 생각하다, 숙고하다confer) ponder [on, over]

Precede

앞서다
confer) precedence : 우선
confer) in order of precedence : 우선순위

Premise
전제

Presume
추정하다, 간주하다, 상정하다

Problematic문제가 있는

Profound엄청난, (지식이)깊은, 심오한

Q

Quadratic
이차의

R

Radical
근본적인, 철저한, 옮기다, 이동하다, 바뀌다, 달라지다

Rational number

유리수

Remainder
나머지, 재고품

Roughly대략, 거의, 거칠게, 꺼칠꺼칠하게

Run out of steam 흥미/에너지 따위를 갑자기 잃은 상태
example) It was running out of steam, so new was needed

S

Second nature to someone
누군가에게는 아주 쉬운 일

Solely
오로지, 단독으로

Span
기간, 폭/너비, 다양성, (~기간에) 걸치다, 포괄하다, 아우르다, 가로지르다

Sprinkle
뿌리다, 간간히 섞다

Substitution 교체, 대체, 대용품

Symmetry대칭, 균형

Syntactic sugar(Wikipedia explanation)
컴퓨터 과학에서 읽기/표현하기 쉽게 하도록하는 표현법을 의미한다. 예를 들면 Scala에서는 ::(cons)를 이용해 List를 생성할 수 있다.

Synthesize합성하다, 종합하다,
confer) synthetic : 합성한, 인조의, 종합적인, 인조물

T

Tedious
지루한, 싫증나는

Tempt유혹하다, 유도하다

Thorough철저한

Trait특성

Turn out모습을 드러내다, 나타나다, (어떠한 방식으로)되다, 되어가다, ~으로 밝혀지다

U

Unsound
부적절한, 오류가 있는, 믿을 수 없는, 견고하지 않은, 불안정한

V

Varying 

(연속적으로) 바뀌는, 변화하는, 가지각색의

W

Word by word 한자 한자, 한 글자 한 글자씩

Work off
풀다, 해소하다, 갚다

Work out 
운동하다, (일이) 잘 풀리다, ~로 계산되다

X
Y
Z

[TroubleShooting] intellij Failed to load JVM DLL

If you see this error :

Error launching IDEA

Failed to load JVM DLL {Path}\server\jvm.dll

If you already have a 32-bit JDK installed, define a JAVA_HOME variable in Computer > System Properties > System Settings > environment Variables.

You might execute intelliJ 32bit not 64bit even though your machine is 64bit one. so executing intelliJ 64bit may be helpful. Go to IDEA_HOME(path which your intelliJ is installed) and go to bin directory, and execute idea64.exe

but if it still does not work check below. There are 3way which you can

1. You must set JAVA_HOME in system environment properties like below. and execute your intelliJ again.

System variable value

Path variable value

2. If it still does not work, set IDEA_JDK to JAVA_HOME and execute your intelliJ again.

3. if it still does not work(damn...), delete jre64 directory in your intelliJ home. In my case, my intelliJ home is C:\Program Files\JetBrains\IntelliJ IDEA {yyyy.m.d}

Remove jre64

Then you can see that your intelliJ work properly

Done!

If you still does not work, then give up, and throw your machine

[TroubleShooting] intellij가 다음과 같은 에러와 함께 실행이 안 되는 증상 해결; Failed to load JVM DLL

윈도우를 새로 깔고 intelliJ를 잘 사용하다가 어느날 갑자기 아래와 같은 오류메시지와 함께 intelliJ가 켜지지 않습니다.(왜 잘되다가 안 된건지 아직도 의문;)

Error launching IDEA

Failed to load JVM DLL {Path}\server\jvm.dll

If you already have a 32-bit JDK installed, define a JAVA_HOME variable in Computer > System Properties > System Settings > environment Variables.

아니... JAVA_HOME은 원래 설정되었었는데 왜 갑자기 이 ㅈㄹ인걸까...

혹시 이것저것 다른 언어 다른 IDE깔면서 충돌이 난 걸까...

이미 저는 이성이 마비되어, 원인 파악이고 뭐고 그냥 손쉬운 방법을 선택하고 맙니다.

그거슨 바로... 시스템 복원 ㅎㅎㅎ...

어차피 집에서 놀고 있으니 복원시켜놓고 내일 아침에 일어나면 잘 되겠지 했으나...

???????

아니 원래는 잘 되었었자나...

내가 널 이용해서 scala 프로젝트도 import 하고 그랬었자나...ㅠㅠ

그래서 환경변수에 온갖 생쇼를 다해봅니다.

사용자 계정에만 JAVA_HOME을 설정해보기도 하고

시스템 계정에만 JAVA_HOME을 설정해보기도 하고

둘 다 해보고

결론은 헛발질이었습니다 ㅠㅠㅠㅠㅠㅠㅠㅠ

하.........

이성을 찾고 구글링을 해봅니다.

Query : intellij Failed to load JVM

첫 번째 God Stackoverflow 질문과 답
>작성자가 환경변수 Path에 문제의 dll을 넣은 상황(대체 왜...?)
>응 아니야 not working!

두 번째 질문과 답
>오.. 나랑 비슷
>Path의 JAVA_HOME\bin을 맨 첫번째로 위치하게 하면 해결된다라네? 그게 무슨 상관이지?
>응 너도 아니야 not working!

그 외에도 기타 이것저것 해보았지만 모두 not working!

다시 한 번 이성을 가다듬어봅니다.

분명 무언가 설정파일이 있을것이야...

그래서 intelliJ가 깔려 있는 디렉토리로 (C -> Program Files -> jetBrain) 가봅니다.

근데 jre64? Java Runtime Environment 64? 아무리봐도 jre64 이거 좀 수상해...

일단 bin으로 간 후 대체 어디서 저 망할 jvm.dll을 가져오려는걸까 뒤져봅니다.

그래서 찾은 것은 바로 idea.bat 이놈쉐키...

왜때문에 JAVA_HOME가 아닌 IDEA_JDK가 우선순위가 높은거죠? jet대가리 형님들... 아마 불짱한 개발자들이 java 안깔고 intelliJ를 쓸까봐 그런가...

그렇다면 방법은 두 가지

1. 저 스크립트 코드의 순서를 조정한다

2. jre64를 제거하면 IDE켤 때 못 찾아서 JAVA_HOME을 참조하겠지?

스크립트 코드 순서 조정은 혹시 잘못 건드릴 수도 있으므로 Pass

플랜2로 간다. jre64 bye bye

그렇다면 결과는?

잘 됨 ㅇㅇ...

요약.

rm -rf IDEA_HOME(e.g C:\Program Files\jetBrain\idea{version}\jre64

그러나 사실 이건 64bit 컴퓨터에서 intelliJ 32bit로 실행시켰을 가능성이 높다.

jre64를 지우기 전에, 먼저 intelliJ가 깔린 폴더의 bin디렉토리의 idea64.exe를 실행시켜보자. 그래도 안된다면 위처럼 jre64를 지우던가, 아니면 IDEA_JDK라는 환경변수명을 JAVA_HOME과 동일하게 지정하면 정상 동작된다.

[Java] Ergonomics - Hotspot VM 문서를 보며 이해하기

Ergonomics의 사전적 의미는 "인체 공학의"라는 뜻입니다만, 이걸 정확히 어떻게 번역해야할지 몰라 그냥 영어를 썼습니다. 사람에 따라 다르고 변수가 많아 이를 다루는 인체 공학의 성격과, JVM의 GC 설정 역시 machine에 따라 다르고 애플리케이션에 따라 변수가 생길 수 있는 상황이 비슷하기 때문에 Ergonomics라는 단어를 쓴 걸로 이해하면 되겠습니다.

Ergonomics는 JVM과 Garbage collection이 애플리케이션의 성능을 높이기 위해 행위 기반의 휴리스틱 조절과 같은 처리들을 일컫습니다.

JVM은 platform에 따라서 garbage collector와 heap 크기, 그리고 런타임 compiler의 기본 선택이 달라집니다. 다양한 애플리케이션 타입에 따라 다양한 설정이 있을 수 있는데 이에 따른 command line 튜닝을 더 적게 하기 위해서죠. 게다가 행위 기반의 튜닝은 애플리케이션의 동작에 따라 heap 의 크기를 동적으로 최적화하기도 합니다. 이번 포스팅에서는 기본 설정과 행위 기반의 튜닝에 대해 살펴볼 것입니다. 여기서 기본 설정이 어떤가를 이해하고, 상세한 설정에 대해서는 다른 섹션에서 다루도록 하겠습니다.

Garbage Collector, Heap, and Runtime Compiler 기본 설정

아래와 같은 물리 스펙의 서버가 기준입니다.

• 2개 이상의 물리 프로세서
• 2GB이상의 물리 메모리

위 경우엔 아래가 기본입니다.

• Garbage-First (G1) collector
• 물리 메모리의 1/64의 초기 heap 크기(16GB machine일 경우 256MB입니다)
• 물리 메모리의 1/4의 최대 heap 크기(16GB machine일 경우 4GB입니다)
• Tiered compiler, using both C1 and C2

행위 기반의 튜닝

HotSpot VM garbage collectors는 정지 시간 최소화 혹은 애플리케이션 throughput 향상, 두 목표 중 하나에 최적화 된 설정을 할 수 있습니다. 만약 둘 중 하나를 만족시켰다면, 나머지 하나를 최대한 만족시키려고합니다. 물론 둘을 항상 충족시킬 수 있는 건 아닙니다. 둘 중의 하나도 만족 못 할 수도 있는거죠. 애플리케이션은 최소 살아있는 모든 객체를 위한 공간이 있어야하는데, 다른 설정이 목표 달성이 불가능하도록 될 수도 있는 거죠

최대 정지시간 목표

 정지 시간은 Garbage collector가 애플리케이션을 멈추고 더이상 사용하지 않는 객체들을 정리하여 공간을 확보하는 것입니다. 최대 정지 시간의 목표는 이 정지되는 시간 중 가장 오래 정지되는 시간을 제한하는 것입니다. 평균 정지시간과 이 평균 정지시간의 분산값은 Garbage collector가 관리합니다. 평균은 Garbage collection 시작부터 걸리는 시간이지만 최근에 멈춘 횟수가 많을수록 더 무겁도록 가중될 수 있습니다. 만약 정지 시간의 분산을 더한 평균이 최대 목표 정지 시간보다 클 경우, Garbage collector는 그 목표는 충족되지 않았다고 판단하게 됩니다.

 최대 정지 시간 목표는 command-line option으로 -XXMaxGCPauseMillis=<nnn>으로 줄 수 있습니다. 이 옵션은 Garbage collector에게 <nnn>만큼보다 더 적게 정지하도록 하라는 힌트로 해석됩니다. Garbage collector는 Java Heap 크기와 <nnn> milli초 보다 더 짧도록 다른 파라미터를 조절합니다. 그러나 이렇게 조절함으로써 Garbage collection이 더 자주 일어날 수도 있고, 애플리케이션 전체 Throughput이 감소할 수 있습니다. 그럼에도 불구하고 설정된 정지 최대 정지 시간을 충족 못 시킬 수도 있습니다. 정리하면 -XXMaxGCPauseMillis 옵션은 권고일 뿐입니다. Garbage collector가 최선을 다하겠지만, 보장되는 값이 아니라는 점에 주의하셔야합니다.

Throughput 목표

이 목표는 Garbage를 수집하는데 걸린 시간이라는 측면과, Garbage collection과 별개의 애플리케이션 시간에 관련된 값으로 측정된 것입니다.

 command-line 옵션으로는 -XX:GCTimeRatio=<nnn>으로 지정할 수 있습니다. 이 비율은 Garbage collection시간과 애플리케이션이 동작하는 시간의 비율로 1/(1+nnn) 값입니다. 예를 들면 -XX:GCTimeRatio=19라면, 1/(1+19) = 5%이며 이는 전체 실행시간에서 Garbage collection 시간이 5%이하로 차지하도록 권고하는 값입니다.

Garbage collection의 소요시간은 실행 정지를 유발하는 모든 Garbage collection의 총 시간입니다. 만약 Throughput 목표가 충족되지 않는다면, Garbage collector가 가능한 행동은 수집 정지 사이 애플리케이션이 정상 동작하는 시간을 늘릴 수 있도록 heap size를 늘리는 것입니다.

만약 Garbage collector가 위 두 목표를 모두 충족시켰다면, 목표 중 하나가 충족되지 않도록 heap 크기를 줄입니다. Garbage collector가 사용할 수 있는 최대 최소 힙크기는 -Xms=<nnn>과 -Xmx=<mmm>으로 각각을 설정할 수 있습니다.

튜닝 전략

만약 기본 최대 heap size보다 더 크게 할 필요성을 알지 못한다면 heap을 최대값으로 설정하지 마세요. 딱 애플리케이션에서 충분한 만큼만 Throughput 목표로 설정하세요.
애플리케이션의 행동 변화는 heap이 늘었다 줄었다하는 크기 변화를 일으킬 수 있습니다. 예를 들면 애플리케이션이 어떠한 이유로든 메모리에 많은 할당을 한다고 합시다. 그러면 같은 throughput을 유지하기 위해 heap은 늘어나게 됩니다.
만약 힙 크기가 최대 크기로 늘어나고 throughput 목표가 충족되지 않는다면, 그건 throughput 목표 대비 heap 최대 크기가 너무 작은 것이라고 할 수 있습니다. 최대 heap 사이즈를 플랫폼의 최대 물리 메모리와 가까운 값으로 설정하되 메모리 swap이 일어나지 않도록 조정하세요. 그리고 다시 애플리케이션을 실행하시면 됩니다. 만약 그래도 throughput 목표가 여전히 충족되지 않았다면, 애플리케이션 실행시간에 대한 목표가 사용 가능한 메모리량에 비해 너무 높은 것입니다.
만약 Throughput 목표가 충족될 수 있지만, 정지시간이 너무 길다면, 최대 정지시간 목표를 설정하세요. 이 목표를 설정한다는 것은 throughput 목표가 충족되지 않을 수 있다는 것을 의미하며, 애플리케이션 특성에 따라 적절한 값으로 타협하여 설정하세요.


Garbage collector가 목표를 충족을 위해 heap사이즈를 위아래로 조정하는 것은 자연스러운 일입니다. 애플리케이션이 안정 상태에 도달했더라도 그럴 수 있습니다. Throughput 목표는 heap크기가 커져야 유리하며, 최대 정지시간은 작아져야 달성하기 쉽기때문에 이 두 목표는 상충될 수 있습니다.

[Java] GC introduction - Hotspot VM 문서를 보며 이해하기

이 문서는 Oracle Java10의 문서를 기반으로 이해한 내용을 거의 그대로 정리한 것입니다.

1. GC란 무엇인가?

Garbage collector는 문서에 다음과 같이 정의되어 있습니다.

Garbage collector는 다음과 같이 자동으로 동적 메모리 관리를 수행하는 것이다.

• 운영체제로부터 메모리를 할당하고, 또 할당 받은 메모리를 돌려준다.(응?)
• 애플리케이션에게 요청받은 메모리를 나눠줍니다(응?)
• 애플리케이션에서 메모리의 어느 부분이 여전히 사용하는지 판단한다.
• 사용하지 않는 메모리를 애플리케이션에서 다시 사용할 수 있도록 정리한다.

아니, Garbage collector는 메모리를 청소하는 놈 아닙니까?

네 저도 그렇게 알고 있었습니다만, 문서를 보니 할당과 해제를 모두 관리하는 놈이었군요(흠.. 인터레스팅)

계속해서 HotSpot Garbage collector는 그러한 것들의 동작을 효과적으로 하기 위해 다음과 같은 다양한 기술을 사용한다고 합니다.(별거 없음 주의)

• 객체의 수명에 따른 세대 분리로 가장 많이 정리할 가능성이 있는 메모리 영역을 포함한 heap 영역에 집중함.
• 여러 thread를 사용하여 병렬로 동작하거나 애플리케이션 백그라운더에서 동시에 오래동안 동작을 수행한다.
• 살아남은 객체를 밀집 시킴으로써 여유 있는 공간들이 연속적으로 이어진 더 큰 공간이 되도록 함

자 그럼, 왜 적절한 Garbage Collector 선택이 중요할까요?

Garbage collector의 목적은 동적 메모리 관리를 애플리케이션 개발자가 하지 않도록 하기 위함입니다. C의 포인터를 써보신 분은 알 것입니다. alloc - free를 개발자가 명시적으로 함으로써 받게되는 스트레스를. 물론 Java 개발자들은 "개발은 편하지만 관리는 아니다"라는 점을 깨달으실겁니다. 세상의 공짜는 없으니까요. 어찌되었든, 개발자는 동적 메모리의 할당과 해제를 매우 세심하게 객체의 생명주기를 관리하면서 개발할 필요는 없어졌다 이 말입니다. 추가적인 런타임 오버헤드(GC 작업으로 인한)라는 비용을 떠안은 대신, 메모리 관리와 관련된 에러를 완전히 제거한 Trade-off의 결과죠.

자 그렇다면, Garbage collector는 언제 문제가 될까요? 몇몇 애플리케이션에서는 절대 문제가 되지 않습니다. 즉, 몇몇 애플리케이션에선 Garbage collection으로 인해 치명적이지 않은 횟수와 시간동안 잠시 멈출 뿐이기 때문에, 잘 동작할 수 있습니다. 그러나, 많은 클래스를 가지고 있는 애플리케이션, 특히 아주 많은 데이터(수 GB급), 많은 Thread와 많은 트랜잭션이 반복되는 그러한 애플리케이션에서는 그렇지 않습니다. 경험상, 지금 이 글을 보고 있을 현업자분들은 거의 모두 어느 정도는 신경을 쓰며 개발해야하며, 이 GC의 튜닝 경험이 경력의 척도가 되기도 합니다.

Amdahl('암달'이라고 읽음)의 법칙을 아십니까? 뜬금없이 웬 Amdahl이냐고요? Amdahl의 법칙에 따르면, 주어진 문제에 있어 병렬 처리 속도의 향상은 문제의 순차적인 부분에 의해서 제한된다고 합니다. 무슨 의미냐구요? 대부분의 부하는 완벽하게 병렬처리화 될 수는 없다는 겁니다. 일부는 항상 순차적으로 해야하기때문에 병렬처리로 항상 해결할 수 있는게 아니라는 말이죠. Java 플랫폼에서는 현재 네 가지의 Garbage collection이 지원되며, Serial GC만 빼고 나머지는 병렬처리로 성능을 향상 시킬수 있으나, Garbage collection작업을 하는 동안의 오버헤드를 가능한 낮게 하는게 정말 중요합니다.

Figure 1-1은 Garbage collection의 overhead와 프로세서 수에 따른 Throughput의 저하를 보여줍니다.

Figure 1-1

위 도표를 보았을 때 저처럼 의문을 가지는 사람이 있을겁니다. 프로세서가 많은데 왜 Throughput이 더 떨어지지? 왜냐면 그게 Amdahl의 망할 법칙때문이거든요. Throughput은 처리"율"을  의미합니다. 아무리 병렬처리를 하더라도, 순차적으로 처리해야하는 부분은 병렬처리로도 답이 없기때문에 무한정 processor를 늘리더라도 오히려 효율은 떨어지는 셈인거죠. GC 시간이 1%대 정도의 어플리케이션이라면 processor가 2개일때보다 32개일 때 효율이 약 20%가 손실되는 셈입니다. GC시간이 30%를 차지하는 (이미 망한) 애플리케이션은 더 처참하죠. Throughput의 90%가 손실됩니다.

이 도표는 작은 시스템을 개발할 때의 throughput 문제는 무시할 정도였지만 큰 시스템으로 scale-up될 때 주요 병목이 될 수도 있다는 것을 보여줍니다. 그러나 병목을 제거하는 작은 개선이 큰 성능 향상을 가져올 수 있다고 볼 수도 있습니다. 충분히 큰 시스템은 올바른 Garbage collector를 선택하고 필요하다면 적절히 튜닝하는 것이 가치가 있다는 것을 말하는 것이죠.

Serial collector는 보통 매우 작은 애플리케이션에 적합합니다. 특히 현대의 프로세서 수준에서 약 100MB 까지의 heap을 요구하는 시스템말이죠. (엔터프라이즈 애플리케이션에서는 과연 이 정도만를 요구하는 시스템이 있을까 모르겠습니다만...) 나머지 collector들은 추가적인 오버헤드와 복잡성을 가지고 있는데 이는 특화된 동작 방식에 대한 비용입니다. 만약 특화된 동작 방식이 필요없는 애플리케이션이라면 그냥 serial collector를 쓰시면됩니다. Serial collector가 적합하지 않을 때가 언제냐면, 많은 양의 메모리와 2개 이상의 프로세서 환경에서 크고 무거운 쓰레드들이 있는 애플리케이션입니다. 애플리케이션이 서버일 때는 G1 collector가 기본 collector입니다(Java9부터 적용되는 이야기입니다. Java9이전은 parallel collector가 기본 collector입니다)