Tag: java

LLL lattice basis reduction algorithm

短短幾天內看到兩個不同的地方用到了 1982 年發現的「Lenstra–Lenstra–Lovász lattice basis reduction algorithm」。

第一個是「Randar: A Minecraft exploit that uses LLL lattice reduction to crack server RNG (github.com/spawnmason)」這篇，作者群利用 LLL 去分析 java.util.Random 的內部狀態，進而得到其他玩家的地點資訊：

Every time a block is broken in Minecraft versions Beta 1.8 through 1.12.2, the precise coordinates of the dropped item can reveal another player's location.

"Randar" is an exploit for Minecraft which uses LLL lattice reduction to crack the internal state of an incorrectly reused java.util.Random in the Minecraft server, then works backwards from that to locate other players currently loaded into the world.

另外一個是在 Hacker News 上面的 id=40080651 提到，前幾天 PuTTY 的 p521 問題在底層也用到了 LLL：

LLL lattice reduction is the same algorithm that can be used for cracking PuTTY keys from biased nonces from the CVE a few days ago. 'tptacek explained a bit about the attack (and links to a cryptopals problem for it, which I can almost pretend to understand if I squint) https://news.ycombinator.com/item?id=40045377

從維基百科的內容也可以看出來 application 非常多，不光是密碼學的領域用到，看起來值得花點力氣來了解...

Java 21 的 ZGC 在 Netflix 的效果

在 Hacker News 上看到連結「Bending pause times to your will with Generational ZGC (netflixtechblog.com)」，發現這篇還沒整理：「Bending pause times to your will with Generational ZGC」，裡面講的東西都有圖有數字 (i.e. Y 軸)，作者是 Danny Thomas。

在這之前他們就已經知道 GC pause 是延遲的重要來源，會導致 timeout & retry：

In both our GRPC and DGS Framework services, GC pauses are a significant source of tail latencies.

That’s particularly true of our GRPC clients and servers, where request cancellations due to timeouts interact with reliability features such as retries, hedging and fallbacks.

第一張圖拉出來的資料是 error rate，白色是上個禮拜的資料，紫色是這個禮拜的資料，而從 G1GC 切到 ZGC 是在 2023/11/16 發生的：

可以看到很明顯的 error rate 改變：尖峰從 2k 下降到大約 0.3k，大約是原來的 1/6 到 1/7 的下降。

第二張圖是 GC 的時間：

可以看到 G1GC 還是偶而會撞到 2 秒，發生時平均值也都還是會 >100ms，切到 ZGC 後直接降到個位數 ms 等級了。

第三張圖是 memory overhead 的部分：

從圖上可以看到上週與本週的對比，導入 ZGC 後記憶體的使用量下降了，不過文裡面倒是沒解釋這點，反而提到 ZGC 比起 G1GC 有個固定的 3% overhead：

ZGC has a fixed overhead 3% of the heap size, requiring more native memory than G1. Except in a couple of cases, there’s been no need to lower the maximum heap size to allow for more headroom, and those were services with greater than average native memory needs.

第四張則是 Huge Pages 的差異，這邊要注意這張圖的 Y 軸不是從 0 計算：

可以看到在開 Huge Pages 後，在 RPS (request per second) 不變的情況下 CPU 使用率是有下降的，大約從 50% 降到 45% 左右，不過這張圖的時間跨度有點少，應該是要拉長一點的圖... 不過既然被提出來了，就假設 Netflix 內看起來應該是有這個趨勢，只是抓圖的時候懶了點？

整體算是大成功？

ClickHouse 弄了一個 C++ 寫的 ZooKeeper drop-in replacement：ClickHouse Keeper

在 Hacker News 上看到「ClickHouse Keeper: A ZooKeeper alternative written in C++ (clickhouse.com)」，原文是「ClickHouse Keeper: A ZooKeeper alternative written in C++」。

在 distributed coordination 這個領域目前應該是 etcd 比較知名，但 Apache ZooKeeper 畢竟算是元老，還是有不少應用程式會把 ZooKeeper 當作基礎建設在用。

因此 etcd 也包了一個 zetcd，可以用 etcd 當作底層結構，但提供 ZooKeeper API 的介面讓應用程式使用：

Serve the Apache Zookeeper API but back it with an etcd cluster

這次 ClickHouse 的人搞出一個用 C++ 寫的 ClickHouse Keeper，定位是 drop-in replacement，想要解決現有的應用程式遇到的記憶體資源問題。

從開頭的說明就可以看到著重在這塊：

up to 46 times less memory than ZooKeeper ​​for the same volume of data while maintaining performance close to ZooKeeper.

而對於新的應用程式，在開發時應該就不太會選 ZooKeeper 了，畢竟連 distributed lock 都得自己操作 znode 把功能疊出來 (像是官網很貼心的還提供了「ZooKeeper Recipes and Solutions」，裡面提供了 lock 的方法)，而這種事情太累，用 etcd 方便太多...

Java 21 (LTS) 推出

Hacker News 上注意到 Java 21 的消息：「JDK 21 Release Notes」、「Java 21 / JDK 21: General Availability」、「OpenJDK JDK 21 General-Availability Release」。

對於沒什麼在寫 Java 的人來說 (也是等於比較沒有在接觸 Java 圈子消息的人)，比較意外的是這是推出的是 LTS 版本，距離上次的 LTS (Java 17) 才兩年前 (2021/09/14)：

JDK 21 will be a long-term-support (LTS) release from most vendors, including Oracle. If you’re upgrading from the previous LTS release, JDK 17, then you have many more JEPs to look forward to, summarized here:

翻了一下 Java version history，可以知道同時支援的 LTS 版本變成四個了，而最近一次會終止的會是 Java 11，Red Hat 會在 2024/10 終止，而 Oracle 會在 2026/09 終止，這中間還會不會再增加 LTS...？

雖然沒什麼在寫，但還是常常會看到有人提到這次引入了 Virtual Threads 與 Generational ZGC，這應該是討論度最高的。

看了 Virtual Threads 的說明，有種「反璞歸真」的感覺...

在二十年前的時候，就已經有很多 userland threading library，讓應用程式可以用 threading design pattern 開發程式，而當時 x86 下的作業系統開始要遇到多 CPU 的環境，才開始在 kernel 裡支援 threading，讓應用程式裡面的 threading 可以打散到多個不同的 CPU 上面。

記得當年 FreeBSD 4 之後對 SMP 與 threading 的爭論導致分家出 DragonflyBSD，而 FreeBSD 的多 CPU 效能與穩定性要一直到 FreeBSD 7 才穩了下來。

現在 Java 反過來為了降低 OS thread 造成的 overhead，讓 java.lang.Thread 可以跑在 userland 裡面，不要用 kernel 提供的 OS thread...

另外又讓我想到 kqueue、epoll 以及 libevent 的事情了，不過這扯遠了...

Mac 上用 Homebrew 安裝 Java 的方式

寫個自己看的，順便整理一些簡單的歷史。

一開始可以先看一下 java 跑起來如何：

$ java --version
The operation couldn't be completed. Unable to locate a Java Runtime.
Please visit http://www.java.com for information on installing Java.

順便一提，這邊的 java 可以用 which java 看到是出自 /usr/bin/java。

然後透過 Homebrew，可以選擇不同的 JDK 套件安裝，在網路上常見的答案是 temurin (adoptopenjdk 的後繼者)：

brew install temurin

這個好處是裝完可以直接用：

$ java --version
openjdk 19.0.1 2022-10-18
OpenJDK Runtime Environment Temurin-19.0.1+10 (build 19.0.1+10)
OpenJDK 64-Bit Server VM Temurin-19.0.1+10 (build 19.0.1+10, mixed mode)

另外一種是 OpenJDK，裝完後還得補個 symbolic link：

brew install openjdk
sudo ln -sfn /opt/homebrew/opt/openjdk/libexec/openjdk.jdk /Library/Java/JavaVirtualMachines/openjdk.jdk

可以看到這個版本的輸出不太一樣：

$ java --version
openjdk 19.0.1 2022-10-18
OpenJDK Runtime Environment Homebrew (build 19.0.1)
OpenJDK 64-Bit Server VM Homebrew (build 19.0.1, mixed mode, sharing)

然後不管哪種裝法都記得設定 JAVA_HOME：

export JAVA_HOME="$(/usr/libexec/java_home)"

基本上就能動了。

AWS 也推出了 GitHub Copilot 的競爭對手 Amazon CodeWhisperer

AWS 推出了 Amazon CodeWhisperer，可以看做是 GitHub Copilot 的競爭產品：「Now in Preview – Amazon CodeWhisperer- ML-Powered Coding Companion」，在 Hacker News 上的討論還不多：「Copilot just got company: Amazon announced Codewhisperer (amazon.com)」。

目前還是 Preview 所以是免費的，但也還沒有提供價錢：

During the preview period, developers can use CodeWhisperer for free.

另外目前提供的程式語言只有 Python、Java 與 JavaScript：

The preview supports code written in Python, Java, and JavaScript, using VS Code, IntelliJ IDEA, PyCharm, WebStorm, and AWS Cloud9. Support for the AWS Lambda Console is in the works and should be ready very soon.

至於 training 的資料集，這邊有提到的是 open source 專案與 Amazon 自家的東西：

CodeWhisperer code generation is powered by ML models trained on various data sources, including Amazon and open-source code.

開發應該需要一段時間，不知道是剛好，還是被 GitHub Copilot 轉 GA 的事件強迫推出 Preview 版...

Google 提供掃描 JAR 檔內是否有中獎的 Log4j 的工具

在 Hacker News 首頁上看到 Google 提供了一套用 Golang 寫的工具，可以掃描 JAR 檔裡面是否有中獎的 Log4j：「log4jscanner」，對應的討論在「Log4jscanner (github.com/google)」這邊。

看起來是內部工具，放出來前先把 vcs history 清掉了：

We unfortunately had to squash the history when open sourcing. The following contributors were instrumental in this project's development: [...]

另外討論裡也有人提到「OWASP Dependency-Check」這個工具也可以掃，這套就更一般性了：

Dependency-check automatically updates itself using the NVD Data Feeds hosted by NIST.

受到 Log4j2 影響的清單

最近大家都在忙著補 Log4j2 的安全漏洞 (先前在「Log4j2 的 RCE」這邊有提到)，有人整理了目前受到影響的軟體的清單以及對應的討論連結：「Log4Shell log4j vulnerability (CVE-2021-44228) - cheat-sheet reference guide」。

用這包來翻起來會方便一些，另外也可以順便翻一下有什麼其他軟體中獎...

然後 Cloudflare 的 CEO Matthew Prince 在 Twitter 上有提到從他們家的資料看起來，2021/12/01 就已經有攻擊在外面跑了，這也是之前會說這是 0-day 的原因：

Log4j2 的 RCE

昨天爆出來 Log4j2 的 RCE，看了一下 pattern，只要是 Java stack 應該都很容易中獎：「Log4Shell: RCE 0-day exploit found in log4j2, a popular Java logging package」，Hacker News 上對應的討論在「Log4j RCE Found (lunasec.io)」這邊可以看。

LunaSec 宣稱這是 0-day RCE，不過 Log4j2 的修正版本 2.15.0 在 2021/12/06 出了，而 exploit 被丟出來是 2021/12/09，但不確定在這之前是不是已經有 exploit 在 internet 上飛來飛去了...

丟出來的 exploit sample (CVE-2021-44228-Apache-Log4j-Rce) 是用 LDAP 來打，雖然大多數的 Java 版本不受影響，但還是有其他的面可以攻擊，所以整體上還是很容易打穿，該升級的還是得趕快升級：

Updates (3 hours after posting): According to this blog post (see translation), JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector. In these versions com.sun.jndi.ldap.object.trustURLCodebase is set to false meaning JNDI cannot load remote code using LDAP.

However, there are other attack vectors targeting this vulnerability which can result in RCE. An attacker could still leverage existing code on the server to execute a payload. An attack targeting the class org.apache.naming.factory.BeanFactory, present on Apache Tomcat servers, is discussed in this blog post.

週末苦命時間...

Java 17 (JDK 17)，新的 Java LTS 版本 (然後來看 GC)

Java 17 (JDK 17) 釋出，這是 Oracle 本家新的 LTS 版本，引用的是 jdk-dev 的 mailing list：「Java 17 / JDK 17: General Availability」。另外在 Hacker News 上的討論可以翻一下：「Java 17 / JDK 17: General Availability (java.net)」。

上一個 LTS 版本是 Java 11，所以很自然的也會有從 Java 11 之後的新功能說明：「JEPs in JDK 17 integrated since JDK 11」。

對於只是拿來用，而不是拿來開發的人來說，我的重點都放在 JVM 的 GC 效能以及特性。

從 Java 11 預設的 G1GC 來看，可以看到一些改善，從「JEP 345: NUMA-Aware Memory Allocation for G1」(Java 14) 這個看起來會改善 G1GC 在多實體 CPU 的情況下效能，不過看起來有 -XX:+UseNUMA 這個參數要加。

再來是「JEP 346: Promptly Return Unused Committed Memory from G1」(Java 12) 可以在閒閒的時候跑個 GC 把記憶體給 OS。

接下來是兩個新的 GC (相較於 11 版)，一個是 ZGC，另外一個是 Shenandoah，都沒有取代 G1GC，但兩個都有對應使用的場景。

ZGC 有列兩個 JEP：「JEP 376: ZGC: Concurrent Thread-Stack Processing」、「JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production)」，目標是讓 GC pause time 盡可能的低，另外在 wiki 上面的說明則是有提到目標在 1ms 以下：

The ZGC garbage collector (GC) aims to make GC pauses and scalability issues in HotSpot a thing of the past.

Sub-millisecond max pause times

Shenandoah 列出了「JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector (Production)」，不過先前的「JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)」講的比較詳細，目標是希望 GC 不影響目前正在執行的程式：

Add a new garbage collection (GC) algorithm named Shenandoah which reduces GC pause times by doing evacuation work concurrently with the running Java threads. Pause times with Shenandoah are independent of heap size, meaning you will have the same consistent pause times whether your heap is 200 MB or 200 GB.

可以看出來兩個新的 GC 都是希望降低 pause time，對於 latency 敏感的應用應該都可以測試看看，可以預期整體的 throughput 會低一些。

回頭來看 G1GC，有人跑了 benchmark 測試了 Java 11 與 Java 17 的 G1GC 差異：「How much faster is Java 17?」。

可以看到 G1GC 的改善 (藍色的部份) 看起來還是不少，不過有些情況下是會變慢的。文章裡面還有提到 Parallel GC，這邊就不提了，可以自己看...

等各家 build 出來後來測看看 Cassandra 的效能影響如何...