#chiroito ’s blog

Java を中心とした趣味の技術について

JVM Language Summit 2024 に行ってきた その1

JVMLSに行ってきたので、そこで新しく出てきたことだけを紹介します。

JVM Language Summit は、現在開発中の OpenJDK の機能について2.5日に濃縮して知れる一年に一回しかない機会です。 これらは、数年後にリリースされるでしょう。 これらの新しい機能について、そのコンセプトや、どのように実現するかを話されます。

場所や時期についてはこちらを参照ください。 JVM Language Summit 2023と OpenJDK Comitters' Workshop に参加してきました - #chiroito ’s blog

2024年の今回は、以下について話がありました。

  • Babylon
  • Leyden
  • Valhalla
  • GC
  • Lilliput
  • Integrity
  • Loom

これらについて何が話されたか簡単に紹介します。詳しくは後日公開される動画を確認してください。 現地で聞いた時のメモだけを頼りにこれを書いているため、間違っているかも知れませんがご了承下さい。 後日動画が公開されたら再度確認して修正します。

Babylon

BabylonプロジェクトはJavaのアプリケーションをJava言語とそれが動くCPU以外の場所（SQLやCUDA、GPGPUなど）で動かせるようにすることを目的としてます。 2023年のJVMLSで登場しました。 まだコンセプトレベルの段階です。

去年は Class File API と Code Reflection、Code Modelの紹介だけでした。 これらの中でもCode Modelはとても重要で、ASTとバイトコードの中間に新たなIntermediate representation（IR）を定義します。 去年の発表以降、いくつかの記事が公開され、Code Modelについても具体的に紹介されています。

今回、新たに Code Model Lowというものが出てきました。 Code Modelが高級言語に該当し、Code Model Lowが機械語に近いもののように見受けられました。 他にも、IntelによるSPIR-VとPHIを使ったサンプル実装が紹介されました。 SPIR-Vに対応した Code Model を実装してみたようです。

Babylonの最新情報は、以下にあります。

記事がたくさんありますので、興味のある方はごらんください。

Leyden

Leyden プロジェクトは、Javaのアプリケーションの起動速度を短縮することを目的としています。 今回の発表では、さまざまなアプリケーションの起動速度が 1/3 程度になったと発表されました。

現在Leydenは、JVMの起動時にアプリケーションのクラスをロードおよびリンクされた状態で即座に利用できるようにすることで、起動時間を改善する試みをしているようです。

詳しくはこちらのJEPをご確認ください。

Leydenの最新情報はこちらから確認できます。

LeydenのEarly-Access Buildsはこちらで入手できます。

Leydenの使い方や、ベンチマークの結果はこちらにあります。

Valhalla

Valhallaプロジェクトは、オブジェクト指向プログラミングの抽象化を維持しつつ、プリミティブの性能特性をオブジェクトに組み込むことを目的としています。 これは、Javaオブジェクトモデルに Value Object を導入することで実現します。

今回は、かなりたくさんのことが発表されました。 もっとも大きな事は、変数やメソッドの戻り値がNullを許容するかどうかを指定できるようになることでしょう。 これは、Null-Restricted and Nullable Types と呼ばれます。 Nullを許容しないのは、型の後ろに!を付けます(String!)。 Nullを許容するには、型の後ろに?を付けます(String?)。 他にも、プリミティブ型を参照型のように使えるようにする Enhanced Primitive Boxing も発表されました。

詳しくはこちらのJEPをごらんください。

ほかにも、以下の論文が紹介されていました。

The Saga of the Parametric VM

ほかにもGC、Lilliput、Integrity、Loomなどがありましたが、これらについては、次回紹介します。

OpenShiftにデフォルトのストレージクラスを作成

Single Node OpenShiftを構築したら、ストレージが使えなくて困ったのでその時のYAMLをここに供養しておきます。

apiVersion: hostpathprovisioner.kubevirt.io/v1beta1
kind: HostPathProvisioner
metadata:
  name: hostpath-provisioner
spec:
  imagePullPolicy: IfNotPresent
  storagePools:
  - name: local-storage
    path: "/var/myvolumes"
workload:
  nodeSelector:
    kubernetes.io/os: linux
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: hostpath-storage-class
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: kubevirt.io.hostpath-provisioner
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
parameters:
  storagePool: local-storage

コードはGitHubで管理してます。

openshift-memo/sno-storage.yaml at main · chiroito/openshift-memo · GitHub

OpenShiftにイメージレジストリを構築

背景

QuarkusのOpenShiftエクステンションを使用して、Single Node OpenShiftへデプロイしようとしたらエラーが発生しました。

[INFO] [io.quarkus.container.image.openshift.deployment.OpenshiftProcessor] Applied: BuildConfig wake-on-lan
[ERROR] Failed to upload archive file for the build: wake-on-lan
[ERROR] Please check cluster events via `oc get events` to see what could have possibly gone wrong
[WARNING] [io.quarkus.container.image.openshift.deployment.OpenshiftProcessor] An exception: 'Can't instantiate binary build, due to error reading/writing stream. Can be caused if the output stream was closed by the server.See if something's wrong in recent events in Cluster = InvalidOutput wake-on-lan-1.17d881cb2b5ed3fc Error starting build: an image stream cannot be used as build output because the integrated container image registry is not configured
BuildFailed wake-on-lan-1.17d881cb2d2462e0 Build home/wake-on-lan-1 failed
 ' occurred while instantiating the build, however the build has been started.

Error starting build: an image stream cannot be used as build output because the integrated container image registry is not configured と出力されていたのでイメージレジストリを構築したら無事にビルドができるようになりました。

環境

  • OpenShift 4.15
  • デフォルトの StorageClasses は構成済み

参考

access.redhat.com

イメージレジストリの構築

イメージレジストリを構築しましょう。 全体の流れは以下のとおりです。

  1. イメージレジストリの管理状態の変更
  2. イメージレジストリーストレージの設定

0. 事前確認

事前に以下の4つを確認します。

  • イメージレジストリのPodがいるかどうか
  • オペレータのステータス
  • インスタンスがあるかどうか
  • インスタンスの設定値

イメージレジストリのPodがいるかどうか

リソースがなければOKです。

> oc get pod -n openshift-image-registry -l docker-registry=default
No resources found in openshift-image-registry namespace

以下のようにリソースが表示されればイメージレジストリは設定されてます。そのため、作業は不要です。

NAME                             READY   STATUS    RESTARTS   AGE
image-registry-f79ccc88f-8sm2s   1/1     Running   0          15h

オペレータのステータス

オペレータのステータスでAVAILABLEがTrueになっているか確認します。

> oc get clusteroperator image-registry
NAME             VERSION              AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
image-registry   4.15                 True        False         False      15h

インスタンスがあるかどうか

デフォルトで作成されているclusterというインスタンスがあればOK。

oc get configs.imageregistry.operator.openshift.io
NAME      AGE
cluster   93d

インスタンスの設定値

spec.managementStateがRemovedになっていればOK。

> oc get configs.imageregistry cluster -o=jsonpath='{.spec.managementState}{"\n"}'
Removed

1. イメージレジストリの管理状態の変更

oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"managementState":"Managed"}}'

2. イメージレジストリストレージの設定

2箇所換えます。

  • configs.imageregistry.operator.openshift.io
  • configs.imageregistry/cluster

configs.imageregistry.operator.openshift.io

oc edit configs.imageregistry.operator.openshift.io

こうなっているのを

spec:
  storage: {}

以下のように変えます。

spec:
  storage:
    pvc:
      claim:

configs.imageregistry/cluster

oc edit configs.imageregistry/cluster

以下のようにmanagementStateがRemovedになっていたら

spec
  managementState: Removed

Managedに換える

spec
  managementState: Managed

確認

以下のようにイメージレジストリのPodが表示されればイメージレジストリが使えるようになります。

> oc get pod -n openshift-image-registry -l docker-registry=default
NAME                             READY   STATUS    RESTARTS   AGE
image-registry-f79ccc88f-8sm2s   1/1     Running   0          15h