~ 1s 대기 시간 제어 앱 : Java에 적합합니까?

Question

제 작품에서 우리는 대략 1-2 초 정도의 최대 대기 시간을 갖는 제어 어플리케이션을위한 시스템 아키텍처를 최근 마쳤습니다. IP LAN을 통해 통신하는 소형 ARM 온칩 박스에 분산되어 있습니다.

우리는 고전적인 제어 시스템 언어이기 때문에 처음에는 C 또는 C++을 사용할 것으로 예상했습니다. 응용 프로그램을 구현하는 방법을 논의한 후에 C++에는 매우 제한된 양의 라이브러리가 있고 인트로 스펙이 없으며 개발 속도를 늦출 수있는 몇 가지 속성이 있음을 알았습니다. 제 동료는 Java가 그 일에 도움이 될 것이라고 제안했습니다.

컨트롤 앱의 GC 실행 지연에 대해 무서워하고 RAII를 삭제하기를 꺼려합니다. 앱에서 많은 외부 리소스 (소켓, 파일 핸들, 외부 libs 등).

다음과 같이 프로/사기꾼 목록 현재 :

병렬 GC와 메모리 단편화는 GC의 대기 시간이 문제가 아니었고 경우 in this AMD article

내가 자바를 사용 싶어요 언급

C++ 

+ RAII - Easy resource management - it will be a complex system 
+ System language - speed if we cant't find a JIT VM for our ARM 
+ No GC - no big worst case latencies from the GC 
+ Easy to integrate with some shared mem libs that we have to interface with 
- Fewer free as in beer libs 
- Lacks introspection - Mapping classes to DB and external data formats (XML)  
    would benefit from this (ORM /JAXB) approach 
- Easy to shoot one self in the foot - hard and expensive to find programmers 
    which don't make big mistakes 
- Memory fragmentation - needs tuning and workarounds 

Java 

+ Huge amount of libs 
+ Introspection - serialization becomes a breeze (see C++ section) 
+ Easier to find 'good enough' programmers 
- No RAII - Client has to remember finally or you leak 
    resources. IMO Java programmers tend to ignore this 
    problem unless they have server app background. 
- No System Language - possibly slower although ARMj could alleviate this 
- GC - latency might go up (don't know if parallel GC will work - seems that 
    you might get fragmentation, see note below). 
- Need to write JNI for the shared mem libs that we interface with 
- Maybe ORACLE will eat us 

우리 RAII를 얻을 수 있습니다. 따라서나는 RAII를 가지고 있고 좋은 대안으로 사용될 수있는 다른 언어를 조사해 왔으며 지금까지 D, Ada, VB, Perl, Python (C), PHP, tcl 및 Lua가 일종의 범위를 벗어난 콜백. 아마도 D, Python 및 ADA가 제어 앱에 적합 할 수 있다고 생각합니다. D와 ADA를 가장 좋아합니다.

내 질문은 : 이것에 대한 권장 사항이 있습니까? Java는 실행 가능한 옵션입니까? 언어를 선택할 수 있다면 무엇입니까?

Answer 1

GC는 폐기 된 개체에서 메모리를 회수하기 위해서만 사용됩니다. 아주 적은 자원을 버리면 아주 짧은 GC를 얻을 수 있습니다.

많은 소켓, 파일 핸들, 외부 라이브러리의 핸들을 사용할 수 있지만 얼마나 빨리 버릴까요?

전체 GC는 조각화를 제거하도록 설계되었습니다. 모든 메모리를 복사하여 연속적으로 사용합니다. 이것이 비용이 많이 드는 이유입니다. 따라서 대기 시간이 중요한 경우에는 최소화해야합니다. 즉, 전체 GC가 100 밀리 초 이상 걸릴 경우 심각한 성능 문제가 발생합니다. 그것은 그렇게 높지 않아야합니다.

IMHO, 나는 짧은 시간 안에 10ms, 99 % +의 대기 시간을 가진 제어 시스템을 개발할 수 있어야한다.

Answer 2

아마도 자바를 사용하기를 원한다면 개념 증명이 필요합니다. 간단한 프로토 타입과 스트레스 테스트를 작성하여 가비지 수집 중에 높은로드 시간이 얼마나되는지 조사 할 것을 제안합니다. 그런 다음 다른 수집기 유형을 체크 아웃하십시오. low pause collector.

RAII 인자 나는 정말로 이해하지 못한다. C++에서는 자바보다 메모리 누출을 더 쉽게 만들 수있다.

Answer 3

나는 그러한 환경에서 GC (분명히 내가 본 모든 JVM에서 구현 된 것)에서 벗어날 것이다. 당신은 영원히 문제의 벽에 머리를 두드리는 것입니다.

그러나 RAII 인수가 매우 약한 것처럼 보였습니다. 코드 검토 및 기타 교육이 필요하므로 팀에서 이러한 문제를 잘 이해할 수 있습니다.모든 언어에서 경험이 부족한 프로그래머/부족한 프로그래머가 놓칠 수있는 결함이 있기 때문에 적절하지 않은 언어를 제외하는 것은 매우 나쁜 이유입니다.

나는 당신이 필요로 할 때 당신이 더 많은 통제력을 가지고있는 C# (나는 Mono에 대해 생각하고있다)을 놓쳤다는 것을 당신의 목록에서 느꼈다. 귀하의 환경에 적합한 지 여부는 모르겠지만 VB 목록을 언어 목록에 나열하면 이는 명백한 감시였습니다.