LMAX 팀이 Java를 사용하고 GC를 피하기 위해 아키텍처를 설계 한 이유는 무엇입니까?

LMAX 팀 이 Java로 LMAX Disruptor 를 설계했지만 모든 설계 포인트가 GC 사용을 최소화하는 이유는 무엇 입니까? GC를 실행하지 않으려면 왜 가비지 수집 언어를 사용해야합니까?

그들의 최적화, 하드웨어 지식 수준 및 그들이 생각하는 생각은 훌륭하지만 왜 Java입니까?

Java 또는 다른 것에 반대하지 않지만 왜 GC 언어입니까? 왜 GC없이 D 나 다른 언어를 사용하지 말고 효율적인 코드를 사용할 수 있습니까? 팀이 Java에 대해 가장 친숙한 것입니까, 아니면 Java가 보지 못하는 독특한 이점을 가지고 있습니까?

수동 메모리 관리와 함께 D를 사용하여 개발한다고 가정하면 차이점은 무엇입니까? 그들은 이미 저수준을 생각해야하지만, 시스템의 기본 성능을 최대한 발휘할 수 있습니다.

성능 최적화 와 완전히 안전 해제 사이 에는 큰 차이 가 있기 때문에

GC의 수를 줄임으로써 프레임 워크의 응답 성이 향상되고 (아마도) 더 빠르게 실행될 수 있습니다. 이제 가비지 수집기를 최적화한다고해서 가비지 수집을하지 않는 것은 아닙니다. 그것은 그들이 덜 자주하는 것을 의미하며, 그렇게 할 때 정말 빠릅니다. 이러한 종류의 최적화에는 다음이 포함됩니다.

1. 작은 버리기 오브젝트를 사용하여 생존자 공간으로 이동하는 오브젝트 수를 최소화합니다 (즉, 하나 이상의 가비지 콜렉션에서 살아남은 것). 생존자 공간으로 이동 한 오브젝트는 수집하기 어렵고 여기서 가비지 콜렉션은 때때로 전체 JVM을 동결시키는 것을 의미합니다.
2. 시작할 객체를 너무 많이 할당하지 마십시오. 젊은 세대 객체는 할당 및 수집이 매우 저렴하므로 조심하지 않으면 역효과를 낼 수 있습니다.
3. 어린 물건을 쉽게 모을 수 있도록 새 물건이 오래된 물건을 가리키고 다른 물건이 아니라는 것을 확인하십시오.

성능을 조정할 때는 일반적으로 자주 실행되지 않는 코드를 무시하고 매우 구체적인 "핫스팟"을 조정합니다. Java로 그렇게하면 가비지 수집기가 여전히 어두운 모서리를 돌 보도록 할 수 있습니다 (많은 차이가 발생하지 않기 때문에) 꽉 루프에서 실행되는 영역에 대해 매우 신중하게 최적화합니다. 따라서 최적의 위치와 그렇지 않은 위치를 선택할 수 있으므로 원하는 곳에 노력을 집중할 수 있습니다.

이제 가비지 콜렉션을 완전히 끄면 선택할 수 없습니다 . 모든 개체를 수동으로 폐기해야합니다 . 그 방법은 하루에 한 번만 호출됩니까? Java에서는 성능에 미치는 영향이 무시할 수 있으므로 그대로 둘 수 있습니다 (매월 전체 GC가 발생하도록해도 괜찮습니다). C ++에서는 여전히 리소스가 유출되므로 해당 모호한 방법조차도주의해야합니다. 따라서 애플리케이션의 모든 단일 부분 에서 리소스 관리 비용을 지불해야 하며 Java에서는 집중할 수 있습니다.

그러나 악화됩니다.

버그가있는 경우 월요일 보름달에만 액세스 할 수있는 애플리케이션의 어두운 구석에 있다고 가정 해 봅시다. Java는 강력한 안전성을 보장합니다. "정의되지 않은 동작"은 거의 또는 전혀 없습니다. 잘못된 것을 사용하면 예외가 발생하고 프로그램이 중지되며 데이터가 손상되지 않습니다. 그래서 당신은 당신이 알지 못하고 아무 잘못도 일어날 수 없다고 확신합니다.

그러나 D와 같은 경우 포인터 액세스가 잘못되거나 버퍼 오버플로가 발생하여 메모리가 손상 될 수 있지만 프로그램은 알 수 없으며 (안전을 끄고 기억합니까?) 잘못된 상태로 계속 실행됩니다. 데이터, 그리고 아주 불쾌한 일을하고 데이터를 손상시킵니다. 그리고 당신은 알지 못하고, 더 많은 손상이 발생하면 데이터가 점점 더 잘못되고 갑자기 데이터가 깨져서 생명에 중요한 응용 프로그램에 있었고, 일부 오류는 로켓의 계산에서 일어난, 그렇지 않은 작업, 그리고 로켓 폭발, 누군가 다이를 수행하고 회사가 모든 신문의 첫 페이지에 있고 당신의 상사 점은 그것의 손가락 그래서 당신이 말하는 "당신은 있다 성능 최적화를 위해 D를 사용했다고 제안한 엔지니어 는 안전에 대해 어떻게 생각하지 않았습니까?". 그리고 그것은 당신의 잘못입니다. 당신 은 어리석은 행위로 그 사람들을 죽였습니다.

알았어, 대부분의 시간은 그것보다 훨씬 덜 드라마틱하다. 그러나 비즈니스 크리티컬 응용 프로그램이나 GPS 응용 프로그램 또는 정부 의료 웹 사이트 조차 버그가 있으면 매우 부정적인 결과를 초래할 수 있습니다. 문제가 발생했을 때이를 완전히 예방하거나 실패 할 수있는 언어를 사용하는 것이 좋습니다.

안전을 끄는 비용이 있습니다. 네이티브가되는 것이 항상 의미가있는 것은 아닙니다. 언젠가는 발로 크게 쏠 수있는 언어를 위해 조금이라도 안전한 언어를 최적화하는 것이 훨씬 간단하고 안전합니다. 많은 경우의 정확성과 안전성은 GC를 완전히 제거함으로써 몇 초 만에 폐기했을 것입니다. 이러한 상황에서 혼란을 일으킬 수 있으므로 LMAX-Exchange가 올바른 전화를 한 것으로 생각합니다.

그러나 특히 D는 어떻습니까? 어두운 구석을 원한다면 GC가 있고 SafeD 하위 집합 (편집 전에 알지 못했던)은 정의되지 않은 동작을 제거합니다 (사용하는 것을 기억한다면!).

그렇다면 그 성숙도에 대한 간단한 질문입니다. Java 생태계는 잘 작성된 도구와 성숙한 라이브러리로 가득합니다 (개발하기에 더 좋습니다). D보다 Java를 아는 개발자가 훨씬 많습니다 (유지 보수가 더 낫습니다). 재정적 응용 프로그램만큼 중요한 것을 위해 새롭고 인기없는 언어를 사용하는 것은 좋은 생각이 아닙니다. 잘 알려지지 않은 언어를 사용하면 문제가 발생하면 도움을 줄 수있는 사람이 거의 없으며, 찾은 라이브러리는 적은 사람들에게 노출 된 이후 더 많은 버그가있는 경향이 있습니다.

따라서 마지막 요점은 여전히 ​​유지합니다. 심각한 결과로 인한 문제를 피하려면 안전한 선택을하십시오. D의 삶에서이 시점에서 고객은 미친 위험을 감수 할 준비가 거의되지 않은 신생 기업입니다. 문제가 수백만 달러에 달할 수 있다면 혁신 종 곡선을 계속 유지하는 것이 좋습니다 .

Java로 작성된 이유는 내부에 Java 전문 지식이 있으며 C ++이 C ++ 0x / 11과 함께 작동하기 전에 (아직 활발히 개발 중이지만) 작성된 것 같습니다.

그들의 코드는 실제로 이름으로 만 Java이며 sun.misc.Unsafe를 사용하면 Java의 요점을 물리 치고 안전이 제공됩니다. Disruptor의 C ++ 포트를 작성했으며 그들이 제공하는 Java 코드보다 성능이 뛰어납니다 (JVM 튜닝에 많은 시간을 소비하지 않았습니다).

즉, 중단자가 따르는 원칙은 언어에 국한되지 않습니다. 예를 들어 힙에서 할당하거나 해제하는 대기 시간이 짧은 C ++ 코드를 기대하지 마십시오.

이 질문은 틀린 전제를 사실이라고 말한 다음 그 잘못된 전제에 대해 논쟁을합니다.

"GC 사용을 최소화하기위한 모든 디자인 포인트"는 사실이 아닙니다. 혼란의 혁신은 GC와 거의 관련이 없습니다. 혼란스러운 디자인은 현대 컴퓨터의 작동 방식을 똑똑하게 고려하기 때문에 수행합니다. 예상보다 훨씬 덜 일반적인 것입니다. 자세한 내용은 Cliff Click의 강의 http://www.azulsystems.com/events/javaone_2009/session/2009_J1_HardwareCrashCourse.pdf 를 참조하십시오 .

LMax는 Azul의 고객으로 잘 알려져 있습니다. Azul GC를 사용하면 175GB의 힙에서도 문제가되지 않습니다.

그들은 저수준 을 생각 해야 할 것입니다

위는 찾고있는 답변의 절반을 만듭니다. LMAX 블로그 에서 추론을 완료 할 다른 절반 을 찾을 수 있습니다 .

매우 효율적이지만 나사를 조이기가 매우 쉽기 때문에 여러 가지 오류가 발생할 수 있습니다.

LMAX 개발자가 인정한 바와 같이 이와 같은 코드는 Java에서도 개발, 이해 및 디버깅이 매우 어려울 수 있습니다. 저수준 프로그래밍 언어 에 대한 Wikipedia 기사에서 지적했듯이 현재 위치보다 낮은 수준으로 나아가면이 문제가 악화 됩니다 .

저수준 언어로 작성된 프로그램은 매우 작은 메모리 공간으로 매우 빠르게 실행되도록 만들 수 있습니다. 고급 언어로 된 동등한 프로그램은 더 무겁습니다. 저급 언어는 간단하지만 기억해야 할 수많은 기술적 세부 사항으로 인해 사용하기 어려운 것으로 간주됩니다 .

이에 비해 고급 프로그래밍 언어 는 컴퓨터 아키텍처의 실행 의미를 프로그램 사양과 분리하여 개발 을 단순화합니다 ...

Java를 구문 언어로 사용하고 JDK 라이브러리를 사용하지 않으면 컴파일 된 비 GC 언어만큼 빠를 수 있습니다. GC는 실시간 시스템에는 적합하지 않지만 가비지를 남기지 않는 시스템을 Java로 개발할 수 있습니다. 결과적으로 GC는 트리거되지 않습니다.

우리는 Java 언어와 플랫폼이 C / C ++에 비해 많은 이점을 가지고 있다고 생각하며,이를 증명하기 위해 대기 시간이 짧은 일부 Java 구성 요소를 개발하고 벤치마킹했습니다. 이 기사에서는 GC를 사용하지 않는 Java Development 의 기술에 대해 설명한다 .

LMAX는 고성능 인터 스레드 메시징 라이브러리입니다.

다른 사람이 유용하려면 각 스레드가 유용한 작업을 수행하도록 코드를 작성해야합니다. 코드가 Java 또는 C #에있을 가능성이 높다는 것을 감안할 때 코드와 인터페이스하는 언어 선택은 거의 없습니다.

스레딩 모델이 정의되어 있지 않으므로 사용자를 단일 OS로 제한하지 않는 한 C 또는 C ++를 사용하는 것은 좋은 옵션이 아닙니다.

요즘 Java는 많은 소프트웨어 개발의 표준이므로, 다른 이유가 없다면 최선의 선택이 될 것입니다. (로마에서 로마인처럼 할 때…)

Java (또는 C #)로 고성능 소프트웨어를 작성하는 것은 종종 요점을 증명하기 위해 수행됩니다…