はてなブックマーク

個人的に気になっている Project Loom で Virtual Threads がプレビューされたので仕様である JEP を翻訳してみました。 ボリュームが多いため、いくつかのパートに分けて公開していきます。スターやブコメが付くとモチベーションが上がるかもしれません。（上がらないかもしれません） 原文はこちら：JEP 425: Virtual Threads (Preview) 全パートはこちら 日本語訳：JEP 425 : Virtual Threads (Preview) Part 1 - #chiroito ’s blog 日本語訳：JEP 425 : Virtual Threads (Preview) Part 2 - #chiroito ’s blog 日本語訳：JEP 425 : Virtual Threads (Preview) Part 3 - #chiroito ’

個人的に気になっている Project Loom で Virtual Threads がプレビューされたので仕様である JEP を翻訳してみました。 ボリュームが多いため、いくつかのパートに分けて公開していきます。スターやブコメが付くとモチベーションが上がるかもしれません。（上がらないかもしれません） 原文はこちら：JEP 425: Virtual Threads (Preview) 全パートはこちら 日本語訳：JEP 425 : Virtual Threads (Preview) Part 1 - #chiroito ’s blog 日本語訳：JEP 425 : Virtual Threads (Preview) Part 2 - #chiroito ’s blog 日本語訳：JEP 425 : Virtual Threads (Preview) Part 3 - #chiroito ’

私は、OpenJDKのCommitter業や仕事でミドルウェアのSolution Architectとして活動している関係上、最近はコンテナ上でJavaアプリケーションを動かすことが非常に多いです。 KubernetesでJavaアプリを監視する場合には、Elasticsearch+KibanaやPrometheus+GrafanaなどでログやMBeanを監視する方法が一般的に行われています。 Java 11では有償JDKに含まれていた機能がOpenJDKへ寄贈され、JDK Flight Recorder (JFR)として生まれ変わりました。JFRはJVMの内部の情報やその上で動くJavaアプリケーションの様々な情報をほとんど負荷無く記録し、ファイルとして取得できます。このファイルをJDK Mission Controlなどのツールを使って確認し、これまでより詳細に分析できます。 これまで

2020年11月7日（土）に開催された JJUG CCC 2020 Fall にて「パフォーマンスのトラブルシュート入門」というタイトルで話をしてきました。 動画はこちらです。 CCC 2020 Fall A02-パフォーマンスのトラブルシュート入門 スライドはこちらになります。 speakerdeck.com Twitterの履歴はこちらです。#jjug_ccc_a というハッシュタグの 11:00～12:00 の間が私のセッション分になります。 twitter.com Twitter などでいただいた質問は以下になります。当日回答した質問もありますが、質問部分は公開されないと思うのでこちらに記載しておきます。類似の質問はこちらでまとめさせていただきました。 JFR Stream で、jfrダンプがしなくてもモニタリングできるようになったらいいですね。でもEventの始まりと終わりで異常

Java 8 以降の Java 仮想マシンの仕様のうち、各バージョンの差分を洗い出しました。the が that になったり、item が entry になる変更で、文の意味が変らない変更は除いています。 I listed the differences between each version of the Java Virtual Machine specification for Java 8 and later. I excluded changes that do not change the meaning of the statement, such as the changing of "the" to "that" or the changing of "item" to "entry". 元の情報はこちらです。 The original information is h

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 これらについて何が話されたか簡単に紹介します。詳しくは後日公開される動画を確認してください。 現

1 リクエスト目がもの凄く遅くなると言う話を聞いたので分析してみました。 今回は、SpringBootのアプリケーションを OpenJDK 14 で動かしています。そのアプリケーションへ 5 回のリクエストを投げてみて処理のされ具合にどんな違いがあるのかを確認してみます。 分析するツールとして、今回は OpenJDK 8 から使用できる JDK Flight Recorder を使用してみます。このツールは Java 言語を書く開発者には当たり前のように使われているツールです。今回は、アプリケーションを起動して、処理を投げて、分析が完了するまでおよそ 40 秒ぐらいで解析できました。Java言語を書く開発者なら誰でもこれぐらいでできます。ぜひツールの使い方を覚えましょう。 全体の概要 まず始めにJFRを起動して記録を開始します。今回は、検証環境なのでOpenJDK に標準で含まれる設定では

どうも、趣味でOpenJDKのコミッタをやってます。JVMの専門家ではないです。 今回はJITコンパイルによる暖気が十分に行われてから処理を受けられるようにする方法を紹介します。 今回の実装は Oracle の有償機能から OpenJDK へ寄贈され OpenJDK 11 に追加された JDK Flight Recorder（JFR）と OpenJDK 14 に追加された JFR Event Streaming を使用します。 JITコンパイルイベント OpenJDK では、JITコンパイラがコンパイルした情報を内部的にイベントとして記録しています。今回はこのイベントを使用していきます。このイベントのデータ形式は以下になります。 @Name("jdk.Compilation") @Category({"Java Virtual Machine", "Compiler"}) @Label("

どうも、趣味でOpenJDKのコミッタをしてます。 とあるブログを読んでいたら気になる点があったので検証してみました。 JITと暖気 Javaプロセスはアプリケーションを動かしながら必要に応じてバックグラウンドでバイトコードをネイティブコードにコンパイルします。このコンパイル時にはCPUリソースを使用します。 コンパイルにはいくつかのレベルがありますが、コンパイルされる前やレベルの低いコンパイルのコードはCPUのリソース効率が悪かったり、アプリケーションの処理中にコンパイルが実行されるとCPUリソースを奪いあったりなどが問題になります。 そのため、Java のアプリケーションで性能を気にする要件がある場合、本番に近いリクエストを投げてコードをJITコンパイルする事があります。これをよく暖気と言います。これにより本番のリクエストが来る前にコードを最適化し、よりCPUリソース効率の高いコードで

これまで通算11個のパッチを書いたので、推薦してもらい、OpenJDKコミュニティ内での信任投票の結果 OpenJDK の Committer になりました。 ※推薦してもらった時点では12個でしたが、その間に1個ダメになったので11個でした。 他のOSSだと1個パッチを書くだけでCommitterと呼ばれるようですが、OpenJDKはしっかりとした任命プロセスがあります。プロセスについては以下のリンクに詳細が記載されています。 http://openjdk.java.net/projects/#project-committer それでは任命プロセスを踏まえて私の例を振り返ってみましょう。私はまず3つのパッチを書いて、Author というロールになりました。これによって、Java Bug SystemやReview用のサーバなどのOpenJDKを開発するためのツールの一部が使えるようにな

これは何？ 今回、パッチを書いたのはJDK-8222489のjcmd VM.system_properties gives unusable paths on Windows。 [JDK-8222489] jcmd VM.system_properties gives unusable paths on Windows - Java Bug System Java 14までにはjcmd <PID> VM.system_propertiesを実行するとURLやWindowsのファイルパスに含まれる:や\と言う出力がエスケープされてhttps\://となったりC\:\\となってしまうよというバグ。タイトルだけみるとon Windowsとあるけど、文字列が該当すればプラットフォーム関係無しに発生します。 どうやって原因を特定したの？ まずは、ソースコード内をVM.system_propertie

Windows 上で Windows Subsystem for Linux (WSL) を使用して OpenJDK 14 の Windows バイナリをビルドする方法をまとめます。 やりがちですが、Windows Subsystem for Linux (WSL)側のUbuntu 側で hg するのは必須ではありません。（やった） Windows側で好きな git クライアントがあればそれを使ってダウンロードしても大丈夫です。 Windows では環境変数とかもやらなくて大丈夫です。 全体の手順は以下のとおり。 Windows の環境構築 Windows Subsystem for Linux (WSL) 上の Ubuntu の環境構築 ソースをダウンロード Windows Subsystem for Linux (WSL) 上の Ubuntu 上でビルド Windows の環境構築 O

自分が使うコマンドをうっかり忘れるときがあるのでその備忘録のために、開発の流れとそこで使ってる内容をメモ。 公式のガイドはこちらを参考にしてください。The OpenJDK Developers' Guide – Index OpenJDK の開発は以下のような流れで行います。 バグを上げる 開発の準備 OpenJDKのソースをダウンロード jtregをダウンロード webrevをダウンロード パッチを書く ビルド jtreg のビルド OpenJDKのビルド テスト 自分が書いたテストを実行 レグレッションテスト レビューの作成 webレビューのアップロード レビュー依頼 コミット・プッシュ ユーザ情報を追加 コミット チェンジセット作成とアップロード 連絡 コミッターになったら Submitリポジトリからソースを取得 Submitリポジトリの設定を変更 SSH クライアントに鍵を登録

Kubernates (k8s) を試したり、複数の物理ホストを使ってクラスタを組みたくなったのですが、何度も作っては壊しをしたいため Vagrantfile を作成してみました。これを使えば複数の物理サーバ上でも簡単に k8s クラスタを構築できます。 今回は以下のように物理ホストが 2 台あって、それぞれでWorker を動かし、片方で master を動かす構成で紹介します。 私の使用している環境では、最低限必要な、master と 1 つの worker の構築は 8分8秒 で完了し、追加となる 2つ目の worker の構築は 3分16秒で完了しました。workerの作成は各 host でパラレルに実行しても大丈夫です。 ※構築時間はhostのマシン性能、ネットワーク転送の性能、プライベートリポジトリの存在など環境に大きく依存します。 クラスタの構築には Vagrant を使用し

先日、JavaOne San Francisco でファンクションのプラットフォームである Fn Project が発表されました。 Fn Project - The Container Native Serverless Framework プロジェクトの Github によると、拡張性かつ高性能なコンテナネイティブなプラットフォームをクラウドやオンプレ問わずさまざまな環境でJavaのみならずGo/Ruby/Python/PHP/JSなど様々な言語を簡単に動かすができます。 また、このプラットフォームには次の図のようなダッシュボードも含まれています。 今回は、チュートリアルにある内容を Windows 上で実行してみます。Docker Host として VirtualBox 上で Oracle Linux を使用しています。各種コマンドの実行は Windows 上のコマンドプロンプトから

OpenJDK を開発したりソースを見ていると、関数やクラスの定義を追いたくなったり、実行しながら動作を確認したくなることがあります。 多くのエンジニア達は vi や grep 、gdb を使ってるそうです。私にとってCUIでの開発はハードルが高くてかなりつらいので、私は Eclipse CDT (C/C++ Development Tooling) を使って開発してます。JJUG CCC 2017 Spring で、情報を共有して欲しいとの声があったのでここに簡単にまとめました。 1. OpenJDK のビルド 2. Eclipse へインポート 3. Eclipse 上でデバッグ 1. OpenJDK のビルド ビルド手順の詳細はこちらを参照してください。 OpenJDK を Linux でビルドする - #chiroito ’s blog JDK 10 をビルドするコマンドを抜粋する

概要　アンダースコア( _ )で区切られた文字列からキャメルケース(CamelCase)の文字列に変換をExcelで行います。O/Rマッパーなどを利用している場合にテーブル名やカラム名の単語間をアンダースコアで区切り、Javaなどではキャメルケースにして利用するケースがあります。最近のO/Rマッパーではエンティティクラスの自動生成などでソースコードは生成されますが、私は管理ツールなどでこの変換を多用しています。 環境Microsoft Excel 2010(2007でも確認しました) A1セルにAAA_BBB_CCCという文字列が入力されているとします。 アッパーキャメルケース(パスカルケース)式：=SUBSTITUTE(PROPER(A1),"_","") 出力結果：AaaBbbCcc ローワーキャメルケース式：=LOWER(LEFT(A1,1))&MID(SUBSTITUTE(PROP

米国時間の2017年4月19日に dockercon17 で Oracle 製品の docker イメージが正式にサポートされたと発表されました。 Docker Store には、Oracle WebLogic Server、Oracle JDK、Oracle Databaseなどの Oracle 製品がインストールされたイメージがあります。これらの公式イメージは以下の 2 ステップだけで使用できます。 Docker Store でコンテンツを取得 docker コマンドでイメージの取得 Docker Store からではなく Oracle 公式の Docker レジストリ からイメージを取得する方法はこちらです。 Oracle 公式の Docker レジストリからイメージを pull - #chiroito ’s blog Docker Store でコンテンツを取得 Docker St

Oracle 公式の Docker レジストリには、Oracle WebLogic Server、Oracle JDK、Oracle Database、MySQL などの Oracle 製品がインストールされたイメージがあります。これらの公式イメージは Oracle 社のシングルサインオンアカウントを登録するだけで使用できます。 注：日本国内からはまだ利用できません。US、UK、オーストラリアに在住の方は利用できます。（2017年1月31日現在） 日本からも利用できるようになりました。（2017年5月現在） ブラウザで以下の URL から Oracle Container Registry へアクセスし、サインインします。アカウントを Docker リポジトリと紐付ける画面になりますので、紐付けましょう。紐付けが完了した後に再度アクセスすると用意されているイメージのリストが見られるようにな

Oracle 公式のスクリプトを使用して Oracle Database を Docker 上に構築します。今回は Oracle Database Enterprise Edition 12.1.0.2.0 を構築します。 データベースを構築するまでの手順は次の通りです。 oracle/docker-images の準備 インストールバイナリの準備 Oracle Database 環境の作成 データベースの作成 接続確認 oracle/docker-images の準備 Oracle 社公式の Dockerイメージを作成するスクリプト群が Github 上で公開されています。[Clone or download]ボタンを押してダウンロードするか、Git を使用してダウンロードしてください。 github.com docker-images/OracleDatabase ディレクトリが Or

Docker のストレージドライバに ZFS 用のドライバがあると知り、家にある ZFS サーバを ZFS 兼 Docker サーバにしてみました。 参考： docs.docker.com 環境 Oracle Linux 7.3 ZFS on Linux 0.6.5.8 Docker 1.12.3 既存の環境の確認 ZFS は以下の通り storage という名前のプールで構築してあります。 [root ~]# zpool list NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT storage 476G 20.0G 456G - - 4% 1.00x ONLINE - [root ~]# zfs list NAME USED AVAIL REFER MOUNTPOINT storage 20.0G 441G 336K

概要 Oracle 社の公式の Docker の設定ファイルが Github 上で公開されています。 github.com 設定ファイルには様々な製品の物が含まれていますが、今回はこれを使用して Oracle Java の実行環境を構築します。 作業 設定ファイルと Java のサーバランタイムをダウンロードします。次にサーバランタイムを適切な箇所に移動して、Docker イメージを作成します。最後に作成したイメージで Java が使えるか確認します。 Github から docker-images を落とします。git コマンドでも良いですし、ブラウザからZIPファイルをダウンロードも出来ます。docker-images のディレクトリを移行は IMAGES_HOME とします。 Java のサーバランタイムを次のリンクからダウンロードします。 http://www.oracle.com