(p. 27 주석 1번)

Mathematical 은 Mathematica 로 수정되어야 함.
==>
확인 중(2006년 10월 10일: 임성춘)

((p 36) 주석 5)

System.currentTimeMillis() 함수는 1/2 밀리초 단위로 실행할 수 있다.

--

원문: System.current.TimeMillis can take up to half a millisecond to execute.

System.currentTimeMillis() 함수는 최대 1/2 밀리초 까지 수행시간이 걸릴 수 있다.
==>
확인 중(2006년 10월 10일: 임성춘)

((p 64) 세션 4 예제 밑의 첫행 및 tab, p, cb 설명)

(번역문)
객체가 있는 메모리 상태를 그대로 출력한 것이다.
--
(원문)
This dump is a snapshot of the actual object table.
해당 순간의 실제 객체 테이블을 그대로 출력한 것이다.



(번역문)
*** tab[<지수>]
메모리에서 객체가 있는 위치를 뜻한다.
--
원문
***tab[<index>]
The entry location as listed in the object table. The index is of no use for performance tuning.
***tab [<번호>]
객체 테이블에서의 위치



(번역문)
인스턴스와 클래스가 있는 메모리 주소다.
(원문)
Internal memory locations for the instance and class
인스턴스와 클래스의 내부 메모리 주소.


-- 등록자 의견

번역에서는 메모리로 통칭하고 있지만 저자가 객체 테이블과 내부 메모리 위치로 
나누어서 기술하고 있으므로 이것을 살려서 번역하는 것이 좀 더
정확하지 않을까 합니다. 
(사실 이 내용까지 읽을 독자가 얼마나 있을지 모르겠지만서도요..)
==>
확인 중(2006년 10월 10일: 임성춘)

((p 64) 마지막 문단 첫번째줄)

(번역문)
이 예의 첫번째 행은 필드 3개로 구성되어 있다.
(원문)
This first line of the example is followed by lines consisting of three fields
예의 첫 행 후에는 세 개의 필드로 구성된 행들이 따라온다.
==>
확인 중(2006년 10월 10일: 임성춘)

((p 65) 주석 15 첫째줄 마지막, 둘째줄)

(번역문)
루트 객체는 일반적으로 가비지 컬렉트되지 않는 다른 객체를 몇몇 방법으로 참조하기 때문에 ...
(원문)
Rooted objects generally cannot be garbage-collected because they are referenced in some way from other
objects that cannot be garbage-collected.
루트 객체는 가비지 컬렉트되지 않은 다른 객체들에 의해 여러 몇몇 방법으로 참조되기 때문에 일반적으로 가비지 컬렉트될 수 없다.

--
루트 객체가 (가비지 컬렉트될 수 없는) 다른 객체를 참조하는 것이 아니라 그 객체들에 의해서 참조된다것이 원문의 내용.
==>
확인 중(2006년 10월 10일: 임성춘)

((p 75) 페이지 아래 2/3 즈음 tally 메소드의 5행)

(번역문)
if (i = = null)

원문에도 동일한 오류 있음.
==>
확인 중(2006년 10월 10일: 임성춘)

((p 82) 6행)

(번역문)
// 샘플러의 샘플링을 준당시킨다. ~

--

// 샘플러의 샘플링을 중단시킨다. ~
==>
확인 중(2006년 10월 10일: 임성춘)

((p 83) 클라이언트/서버통신 두번째 문단 3-5째줄)

(번역문)
복잡한 페이지를 표시하고 있는 많은 사이트들이 있다. 이런 사이트들은 반드시 그 서버명을 IP 주소 형태로 사용하며, 이 서버 접속이 데이터 전송량의 큰 부분을 차지할 수 있다. 각 사이트들은 서버에 접속해서 데이터를 다운로드 시작한다.

(원문)
Many different sites are involved in displaying the complex page; each site
must have its server name converted to an IP address, which can take many network transfers.[12] Each
site then needs to be connected to and downloaded from.

이 복잡한 페이지를 표시하려면 여러 다른 사이트들에 접속해야 한다. 접속을 위해서는 각 사이트들의 서버명을 IP 주소로 변경해야 하며, 이 작업은 많은 넷웍 전송을 일으킬 수 있다. 주소변환이 끝나면 각 사이트마다 접속한 후, 데이터를 전송받아야 한다.
==>
확인 중(2006년 10월 10일: 임성춘)

((p 95) 첫번째 문단 2~4줄)

(번역문)
최대 힙 크기에 따라 작업을 처리한다고 가정하면, 자바 가상 머신 메모리의 증가는 순수한 가부하로 간주할 수 있을 것이고, 다수의 시스템 호출을 요구하며, 그 결과로 분할된 시스템 메모리가 할당된다.

(원문)
Assuming you've worked out what the maximum heap size should be, then growing the
JVM memory can be considered as pure overhead, requiring multiple system calls and resulting in
segmented system memory allocation. 

=> 필요한 최대 힙크기를 산출해냈다고 가정해보자. 이 경우 초기 메모리에서 시작해 JVM 메모리를 증가시켜나가는 작업은 여러번의 시스템 호출을 필요로 하며, 결과적으로 분할된 시스템 메모리를 만들어내는 순수한 과부하 작업으로 간주될 수 있다.
 

((p 95) 첫째 문단 4~6째줄)

(번역문)
최대 힙 크기에 도달하였음을 알았다면, 최대 힙 크기에서 시작하도록 해서, 힙의 분할을 막고 과부하 증가를 피한다.
(원문)
If you figure that you are going to get to the maximum heap
anyway, then there is a good argument for simply starting out at the maximum heap (the first
suggestion), thus avoiding the growth overhead as well as getting a heap that is less segmented.

=> 어떻게든 최대 힙 크기까지 메모리 사용량이 올라간다고 판단되면, 첫 주장처럼 간단히 처음부터 최대 힙 크기에서 시작하도록 해서 메모리 증가에 따른 과부하를 피하고 힙도 덜 분할되도록 할 수 있다는 주장도 충분히 가능하다.
 

((p 95) 두번째문단 4~5째줄)

(번역문)
~, GC는 최고의 상태로 최적화된다. 즉, 메모리 관리와 유지를 GC가 적절하게 처리한다.
(원문)
and the GC should be optimizing what it does best, i.e., handling and maintaining memory. 

=> GC는 가장 잘 하는 일, 즉 메모리 처리와 관리를 최적화한다.

((p 95) 벤치마크의 고려사항 첫번째문단 3-4줄)

(번역문)
모든 경우에서, 이는 벤치마크에만 적용하는 사항이라는 점에 주의해야한다.

(원문)
In any case, be aware that this may apply to benchmarks presented to you.

=>여러분에게 제시된 벤치마크 결과에 이런 조치가 적용되었을 수도 있다.

(등록자 의견)
presented라는 표현을 쓴 것으로 보아 you 는 
벤치마크 테스트 결과를 보는 사용자라고 생각되지만,
(따라서 이러한 점을 염두에 두고 결과를 판단하라는 이야기)
약한 확률로, you를 벤치마크를 수행하는 엔지니어로 생각해서
'벤치마크 때 성능을 높이기 위해서 위와 같은 조치를 고려해 볼 수도 있다'는
것으로 생각되기도 합니다.
 

((p 96) 힙 튜닝 방법(큰제목))

(번역문) 
힙 튜닝방법

(원문)
Fine-Tuning the heap
=>힙 상세튜닝 

[등록자주: 앞의 Gross Tuning과 대비되는 장]

((p 96) 두번째문단 5-7줄)

(번역문)
튜닝 방법은 개발의 마지막 순간이나 마이크로세컨드 단위의 성능향상이 가치가 있는
안정적인 배포 시스템, 즉 더 이상의 개발이 필요없는 경우에만 적용할 수 있다.

(원문)
Fine-tuning is probably worth doing only where every last microsecond is needed or
for a really stable deployed system, i.e., one that needs no more development.

=> 상세튜닝은 대개 백만분의 일초가 아쉬운 상황이나 추가 개발이 필요없는 
정말로 안정된 운영시스템의 경우에만 수행할 가치가 있다.

((p 96) 네번째문단 8줄)

(번역문)
비슷하게 -XXMaxHeapFreeRatio 매개변수로 힙의 확장을 정할 수 있다.

(원문)
Similarly, the -XXMaxHeapFreeRatio
parameter specifies when the heap should be contracted.

=> 비슷하게, -XX:MaxHeapFreeRatio 매개변수로 힙을 언제 축소할지 정할 수 있다.
또는 
비슷하게, -XX:MaxHeapFreeRatio 매개변수로 힙을 언제 축소할지 정할 수 있다.

[등록자주: 원문에도 -XX:MaxHeapFreeRatio 를 -XXMaxHeapFreeRatio로 잘못 표기함]

((p 97) 두번째문단 3-4줄)

(번역문)
(예를 들어, 10%에서 가비지 컬렉터를 실행하고, 다시 10% 여유 비율을 가지게 되므로, 힙은 확장하지 않는다.)

(원문)
(e.g., 10% is filled, GC runs, and we have 10%
available again so no heap expansion occurs).
=> (예를 들어 10%가 차서, GC를 수행하고, GC수행 결과로 다시 10% 여유 비율을 가지게 되므로 힙 확장이 발생하지 않는다.)

((p 97) 네번째 문단 제목)

(번역문)
점진적 혹은 연속적 GC
(원문)
Incremental or "train" GC

=> 점진적 혹은 트레인 GC
또는
점진적 혹은 기차 GC

[등록자주: 해당 사용되는 알고리즘의 이름이 Train Algorithm이며 이는 
실제 차량(화차/객차)-기차-기차역 의 비유에서 온 것임]
 

((p 98) 두번째문단 6줄)

(번역문)
그러므로 New 공간에서 더 많은 객체가 생성/해제된다.

(원문)
so the more objects that are churned in the new space, the better.

=> 따라서 더 많은 객체가 New 공간에서 해제될수록 좋다.

((p 99) 두번째문단 1-3줄)

(번역문)
가비지 컬렉션은 '모 아니면 도' 식의 영향을 주는 성향이 짙고, 
종종 가비지 컬렉션을 시작할 때가 언제인지를
가비지 컬렉터가 더 잘 아는 경우가 많았다.

(원문)
Garbage collection
was pretty much an all-or-nothing affair, and often you knew better than the garbage collector when it
was a good time to start garbage collecting.
=> 이때의 가비지 컬렉션은 많은 부분 '모 아니면 도' 식의 작업이었고, 
가비지 컬렉션을 언제 시작해야 할지를 
가비지 컬렉터보다 개발자가 더 잘 알기도 했다.

((p 99) 마지막문단 1줄)

(번역문)
핫스팟은 자바 객체를 고유한 내부 자료구조체로 저장하는데,
이는 클래스, 메소드, 필드의 내부 표현이다.

(원문)
HotSpot stores as Java objects some of its own internal data structures, things like the internal
representation of classes, methods, and fields

=> 핫스팟은 클래스, 메소드, 필드의 내부 표현 등과 같은 
핫스팟의 자체 내부 자료구조들을 자바 객체로 저장한다.

((p 100) 네번째 문단 둘째줄)

(번역문)
공유하도록 하는 권고안이 있으며

(원문)
There is a proposal for VMs

=> 공유하도록 하자는 제안이 있으며

[등록자주: 권고안은 보통 (특히 표준 성격의) recommendation에 대한 번역에 많이 쓰이므로
제안으로 하는 것 이 맞을 듯 합니다.] 

((p 101) 19번 주석)

(번역문)
'보호된 모니터링과 서버 프로세스를 메모리 오류 밖으로 잡아라(Catching out Of Memory Errors to Preserve Monitoring and Server Processes)',

(원문)
Catching OutOfMemoryErrors to Preserve Monitoring and Server Processes,"

=> OutOfMemoryError 잡아서 모니터링과 서버 프로세스를 살리자.

((p 101) 두번째문단 2-4줄)

(번역문)
예를 들어, 에키드나 라이브러리를 사용하는 가상 머신은 
자바 애플리케이션을 실행하지 않는 런타임 시스템 프로세스가 될 수 있다.
(에키드나 라이브러리는 제외하고.) 
이 라이브러리는 가상 머신을 시작하는 것과 정확히 동일한 방법으로 
모든 자바 애클리케이션을 실행할 수 있으나, 
모든 가상 머신을 시동할 때, 과부하 자체는 피하지 못한다.


(원문)
For example, a VM using the Echidna library can be a running system process
with no Java application running (except for the Echidna library). The Echidna library can start any
Java application in exactly the same way the VM would have started it, but without all the VM startup
overhead.

=> 예를 들어, 에키드나 라이브러리를 사용하는 VM은 에키드나 라이브러리외에
다른 자바 애플리케이션을 수행하지 않은 채로 시스템 프로세스로 동작중일 수도 있다.
에키드나는 가상 머신과 정확히 동일한 방법으로 VM 의 시동에 따른 과부하 없이
모든 자바 애클리케이션을 실행할 수 있다.  

((p 101) 세번째 문단 1-3줄)

(번역문)
그러나 불행히도 변경한 클래스를 애플리케이션이나 애플릿과 함께 공개 배포할 수는 없다. 
집에서나 엔터프라이즈 애플리케이션에서는 별 문제가 없을 테지만, 대부분 외부에서
컴파일한 클래스를 변경한 것을 배포본에 포함하지는 않는다.

(원문)
Unfortunately, you can't distribute these altered
classes with any application or applet unless you have complete control of the target environment.
Although you often do have this control with in-house and enterprise-developed applications, most
enterprises prefer not to deploy alterations to externally built classes.

그러나 불행히도 수행환경을 완전히 제어할 수 없다면 변경된 클래스들을
애플리케이션이나 애플릿과 함께 배포할 수 없다.
비록 사내에서 개발한 애플리케이션은 수행환경을 충분히 제어할 수 있겠지만, 
대부분의 기업들은 외부에서 제작된 클래스를 변경한 사항을 배포하지 않는다.
 

((p 101) 5문단 2-3줄)

(번역문)
용도가 협소하므로 애플리케이션에 맞추어 제대로 정의한 클래스로 쉽게 대체 할 수 있다.

(원문)
such as
StreamTokenizer (see Section 5.4), are inefficient and can be replaced quite easily since you
normally use them in small, well-defined parts of a program.

=> 는 일반적으로 프로그램의 잘 정의된 작은 부분들에서 사용하므로 쉽게 대체할 수 있다. 

((p 102) 경고 9줄)

(번역문)
등의 방법 중 하나를 택해야한다.

(원문)
The potential workarounds to this
performance issue are all ugly: using an earlier JDK version, replacing the
JDK class with an earlier version, or writing your own class to manage faster
alternative floating-point calculations.

어느 것 하나 깔끔한 해결책이 못된다. 

((p 102) 4문단 3-4줄)

(번역문)
한 종류의 객체를 다루려고 Vector를 이용한는 것보다는 배열을 이용하는 것이 
캐스팅을 피하게 되어서 훨씬 빠르다.

(원문)
but if you are using a Vector for only one type of object, then a custom version with an
array and accessors of that type is faster, as you can avoid all the casts required to convert the generic
Object back into your own type.

=> Vector를 이용해서 오직 한 타입의 객체를 다룬다면 
해당 타입의 배열과 접근자(accessor)를 가지고 있는 맞춤 버젼 Vector가 
Object를 다시 해당 타입으로 변환하기 위해 필요한 캐스팅을 피할 수 있어
훨씬 빠르다.

((p 102) 5문단 4줄)

(번역문)
Long과 같은 기본 자료형을

(원문)
Using Vector for basic data types (e.g., longs)

=>
long과 같은 기본 자료형을

((p 103) 참고 (번역 누락))

(번역문)
(누락됨)

(원문)
There is no specialized class
generation, so there is no performance benefit, and there may even be a slight
performance degradation from the additional casts.

=>
특화된 클래스가 생성되는 것이 아니므로 성능향상이 없으며, 
추가적인 캐스팅으로 인해 약간의 성능저하가 생길 수도 있다.

(p.269 아래쪽의 표)

아래쪽의 표
짧은 행
버퍼없는 입력 스트림
버퍼없는 입력 스티림
8K 버퍼입력 스트림

긴행
버퍼없는 입력 스트림
버퍼없는 입력 스티림
8K 버퍼입력 스트림

==>
아래쪽의 표
짧은 행
버퍼없는 입력 스트림
버퍼 입력 스티림
8K 버퍼입력 스트림

긴행
버퍼없는 입력 스트림
버퍼 입력 스티림
8K 버퍼입력 스트림

(p.309 첫번째 줄)

더 빨리 피교할 수 있는 객체로 대치한다
==>
더 빨리 비교할 수 있는 객체로 대치한다

(p.329 소스코드의 셋째줄)

Tread d1Thread = new Thread(d2);

      
==>
Tread d2Thread = new Thread(d2);