윤경구의 Log on Java

최근 릴리스된 Java 15 버전의 new feature를 보다가 깜짝 놀람. JEP 374: Disable and Deprecate Biased Locking Biased locking은 실제로는 synchronized를 통해 lock을 쓰고 있으나 single thread에서 실행되는 경우가 더 많다고 가정하여 이 경우는 lock 오버헤드 없이 실행되도록 자바의 내부 스택에 상태 필드를 유지하는 방식의 최적화이다. 기존 JDK의 util 클래스들이 기본적으로 synchronized를 하도록 구현되어 있었기 때문인데 그후 sync 없는 클래스들이 API에 대부분 추가되었다. 하지만 여전히 java.io 패키지의 스트림 클래스들은 그대로이긴 한데 실제로는 IO를 하지 않는 ByteArray...Stream 같은 류는 biased locking의 여전한 수혜자이고 예전 API 기반으로 설계되어 Hashtable, Vector, Properties 같은 클래스를 인자로 받는 경우도 마찬가지이다. 물론 biased locking은 contentio n이 발생할 때에는 오버헤드가 있다. 이런 낙관적 최적화는 어느쪽이 더 전형적이냐가 분명할 때 효과가 있다. Java 15에서 biased locking을 제거하면 기존 코드들 중 이건 biased locking 덕분에 큰 차이가 없어 하고 넘어갔던 코드들이 모두 영향을 받을 것이다.  15년 가까이 biased locking을 전제로 decision을 했던 터라  약간 난감하다. 물론 가능하면 StringBuilder,ArrayList 등을 쓰는 건 당연했지만 약간 API적으로 선택이 모호한 경우에는 biased locking을 고려하여 lock free 모듈을 만들지 않고 넘어갔던 경우가 계속 떠오른다. (ByteArray stream 같은 경우는 별도로 Lite 클래스를 만들어 쓰긴 했지만 항상 그럴 수 있었던 건 아니다) 제거를 결정한 근거는 대부분 코드들이 lockfree new API로 옮겨갔다는점과 conte

GraalVM의 Native Image가 리눅스 컨테이너에서 Spring Boot 기반 서비스들을 실행하는 데 점점 더 많이 사용되는 이유 중 하나가 메모리 footprint가 기존 서버 JVM처럼 미리 Heap을 전체 할당하는 방식이 아니라는 것일듯. 참고 : Quarkus - SUPERSONIC SUBATOMIC JAVA A Kubernetes Native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best of breed Java libraries and standards.  GraalVM의 Native Image는 SubstrateVM이라는 유사 JVM(?)을 사용하는데 그야말로 기판에 사용되는 자바 모듈들을 AOT 방식으로 컴파일해서 붙여가는 방식이라서 이렇게 이름을 붙인듯. -Xmx 기본값이 unlimited 이다. 와우! SubstrateVM은 closed world라는 전제로 만들어졌는데 런타임에 사용되는 모듈들은 빌드 타임에도 알 수 있다는 전제이다. 그래서 동적으로 로드되는 자바 코드나 JNI 코드나 다 찾아서 빌드 타임에 미리 함께 빌드되도록 옵션 처리해줘야 한다. 한마디로 상당량의 삽질이 기본 전제된다. ㅠㅠ 그런데 점점 더 활용도가 높아져서 많이 쓰는 모듈들은 (JVM 런타임을 포함해서) 분명 누군가가 이 삽질들을 해놓았을 거라고 기대할 수 있다. 내가 짠 모듈들만 잘 챙기면 많은 경우 해결이 될 것이란 기대... 게다가 graalvm native image는 polyglot이다. 아직 실험적이지만 R과 python 코드를 컴파일할 수 있다. numpy와 pandas 패키지를 포함해서... 서버뿐 아니라 클라이언트 프로그램으로도 java를 좀더 잘 활용할 수 있게 되었다. 대부분 관심이 없겠지만(!) 이제 JavaFX로 작성한 프로그램을 GraalVM Native Image로 쉽게 컴파일할 수 있게 되었다. 윈도우에서 하나의 exe 바이너리로 쉽게 빌드할

  마틴 파울러가 짧은 강의를 통해 소프트웨어 아키텍처란 the important stuff 라고 정의한다. 아키텍처는 두 가지 측면을 가지고 있다고 하는데 "이해를 함께 해야 할 부분"이자 "변경이 어려운 부분"이라고. 이 두가지가 합쳐져서 "중요한 무언가"를 이루는데 이것을 아키텍처라고. 공감하는 부분도 있지만  소프트웨어 아키텍처를 너무 컴포넌트 중심으로 바라보는 것 같다. 시스템 구조적 측면을 단순히 컴포넌트로 보기는 어렵다. 구조의 측면을 고려하면 무조건 변경이 어려운 것은 아니다. 사실 시간의 기준으로 보면 그렇게 어려운 게 아니고 어렵다는 것을 마틴의 얘기 중 하나인 "지식의 깊이"로 보면 맞다고 볼 수 있다. "지식의 깊이"를 가진 사람들이라면 아키텍처는 하나의 aspect처럼 간주될 수 있다. 물론 비즈니스 로직은 잘 동작하고 최소한의 가독성을 가진 코드들로 구성되어 있다는 가정 하에서. 아키텍처는 리팩토링처럼 일상적일 순 없지만 계단식 개선이 간헐적으로 발생해야 하는데, 시간적 관점에서도 hard to change이면 그 소프트웨어의 품질은 나오자마자 이미 한계에 달한 것이 된다. 소프트웨어나 서비스의 아키텍처 측면 품질은 매우 중요한 결정적 요소가 되기 쉬운데 이를 개선하기 위해서는 개발 조직은 아키텍처를 이해할 수 있는 지식의 깊이를 갖춰야 한다고 단순 결론을 내릴 수 있다.