タグ

jvmに関するmanabouのブックマーク (80)

  • JVM勉強会(開発編)を開催しました - 株式会社ヘンリー エンジニアブログ

    こんにちは、SREの戸田です。日はJVM勉強会(運用編)に続けて開催したJVM勉強会(開発編)の一部を公開します。 図1 勉強会はやっぱりGoogle Meetでオンライン開催しました システムプロパティ システムプロパティは環境変数のように、プログラムの挙動を変えるために利用することが多いです。例えばOpenJDKそのものでも Integer.valueOf() で値をどの程度キャッシュするか*1を設定するためにシステムプロパティを使っています。 他にも user.language あたりはよく知られていますし、標準で提供されるシステムプロパティも多数あります。しかし製品コードから直接参照することは基ないと思っていて、 File.pathSeparator などの提供されたAPIを使うことが望ましいでしょう。またシステムプロパティは動的に変更することも可能ですが、システムプロパティを

    JVM勉強会(開発編)を開催しました - 株式会社ヘンリー エンジニアブログ
  • ZOZOMATにおけるJVMの暖機運転の導入と改善効果について - ZOZO TECH BLOG

    こんにちは。ZOZOテクノロジーズSRE部の市橋です。普段は主にAWSを用いてプロダクトのシステム構築、運用に携わっています。今回は弊チームで取り組んでいるZOZOMATのシステム改善業務の一例として、JVMの暖機運転の仕組みを取り入れた話をご紹介します。 ZOZOMATとは お客様の足を3Dで計測するために開発された計測用マットです。ZOZOMATでの計測情報をもとに、の推奨サイズを参照するなどのサービスをご利用いただくことが可能です。ご興味のある方はこちらをご確認ください。 JVMの暖機運転とは 今回テーマとして取り上げるJVMの暖機運転とは何かについて簡単に触れていきます。JVMではJITJust In Time)コンパイラによるコンパイル方式が取り入れられています。これはアプリケーションの実行前にプログラムの全てを機械語にコンパイルするのではなく、プログラムの実行時にコンパイル

    ZOZOMATにおけるJVMの暖機運転の導入と改善効果について - ZOZO TECH BLOG
  • Mandrel: Red HatのQuarkusビルド用のGraalVMのコミュニティディストリビューション - 赤帽エンジニアブログ

    Red Hat で Solution Architect として Quarkus を担当している伊藤ちひろです。 この記事は、Red Hat Developerのブログ記事、Mandrel: A community distribution of GraalVM for the Red Hat build of Quarkus - Red Hat Developer の翻訳記事です。 Javaコミュニティは、開発者とユーザーのニーズに合わせて進化、改善、適応する能力を何度も実証してきました。言語とフレームワークの選択に25年を費やした後も、Javaはエンタープライズ・ユース・ケースでの強力な実績と機能により、現在使用されている言語の中で常に上位に位置しています。Red Hatは長い間、Javaおよびオープンソースソフトウェア開発における強力なリーダーであり、進化を続けるJavaの最前線であ

    Mandrel: Red HatのQuarkusビルド用のGraalVMのコミュニティディストリビューション - 赤帽エンジニアブログ
  • JVM vs DVM

  • GitHub - k0kubun/jjvm: JVM implementation written in Java

    $ java -cp build/classes/java/main com.github.k0kubun.jjvm.JJVM -help Usage: jjvm [-options] class [args...] where options include -cp <class search path of directories and zip/jar files> -classpath <class search path of directories and zip/jar files> A : separated list of directories, JAR archives, and ZIP archives to search for class files. -help print this help message $ java -cp build/classes/

    GitHub - k0kubun/jjvm: JVM implementation written in Java
  • セルフホストで学ぶJVM入門 - k0kubun's blog

    RubyのJIT開発でやろうと思ってることが大体 @_ko1 さんの作業待ちでブロックしていて暇なので何かを書こうと思い、JVMを書くことにした。 まだその辺のアプリを気軽に動かせるレベルでは全然ないが、別に秘密裏に開発する必要もないと思ったので公開した。 github.com これの紹介と、現時点で学べたことをこの記事に記録しておく。 何故JVMなのか 仕事でJVM言語を使っている 僕が所属しているTreasure Dataでは、大雑把に言うと番サーバーのサービスは大体Ruby, Java, Scala, Kotlinで書かれている*1ので、既にRubyのVMはある程度わかる*2ことを考えると、JVMさえ理解してしまえば社内の主要な言語評価系を抑えたことになり、運用面で活躍の機会が増える気がしている。 また、自分が最近一番書いているのはKotlinなのだが、JVMで動かしていることに由

    セルフホストで学ぶJVM入門 - k0kubun's blog
  • TD Tech Talk PLAZMAでBigdamについてしゃべった - たごもりすメモ

    今年はTreasure Dataの東京オフィスができて5年ということも兼ねてPLAZMAというイベントをやっているんだけど、その併催ということで TD Tech Talk をなんと2日間、初めて平日の午後の開催で行った。TD発のOSSが中心になるOSS Dayと、TDの内部実装についてあれこれ話すTD Internal Day。 techplay.jp techplay.jp あれこれ裏方もやっていたんだけど、多くの人に来ていただけたし、楽しんでもらえたような感じだった。またOSS DayとTD Internal Dayともに外部からの人にもしゃべっていただく時間を設けて*1みた。こっちも普段TDのエンジニアだけだと出てこない話がいろいろあって、当によかったと思う。 しゃべった ここ1年(!)やっているBigdamというプロジェクトがあるんだけど、そのプロジェクトの概要と全体の設計におい

    TD Tech Talk PLAZMAでBigdamについてしゃべった - たごもりすメモ
  • オンスタックリプレイスメント(on-stack replacement)の実装を進めなくちゃ - ユウキ木本のPerlテックブログ

    SPVMでJITの実装を進めているだけれど、バージョン1.0に向けて、どうしても実装しておかないといけない機能がある。 それは、バイトコードのループの途中で、ループの回数が増えた時に、ループの途中でJITのコードをコンパイルして、そのまま処理を移し替えるオンスタックリプレイスメントだ。 JavaのHot Spotはもうとっくの昔に、実装している。 オンスタックリプレイスメントがないとどうなる もしループ処理が初回に1億回、回って終わるまで待つとしたら、それが終わるまでJITできない。サブルーチンが1万回実行したら、JITしようという実装は、ループに対応ができない。 だから、ループの途中で、バイトコードからJITでコンパイルされた機械語に切り替える処理が必要になる。 実装方法は、今考えている。 関数はデータ領域と処理からなる プログラムというのは、関数の集まりだ。関数というのは、「引数やロー

    オンスタックリプレイスメント(on-stack replacement)の実装を進めなくちゃ - ユウキ木本のPerlテックブログ
  • JVM関連の最近の出来事〜GraalとOpenJ9〜

    JVM関連の最近の出来事〜GraalとOpenJ9〜 1. JVM関連の 最近の出来事 ~Graal/OpenJ9~ 関西Javaエンジニアの会 / ポノス株式会社 阪田 浩一 @jyukutyo #kanjava 2. 会長だけどじゅくちょー 阪田 浩一 通称: じゅくちょー 関ジャバ会長 JVMが大好き ポノス株式会社(スマホゲーム会社) 3. 私の検索 • Graal • J9 • JIT • HotSpot • JVM • GC 4. 今日は GraalとOpenJ9で “聴いたこと”を 話します 5. 理解しきれておらず 誤ったことを言う 可能性もあります (フォローお願い) 6. Graal 7. Graal • HotSpotでの新しいJITコンパイラ • Java 9でexperimental • Javaで記述されている • 他言語のサポート – http://www.o

    JVM関連の最近の出来事〜GraalとOpenJ9〜
  • JDK9のモジュールとjlinkでアプリ配布向けのJVMを作る - Qiita

    JavaOne2017を前にして、待望のJava9が遂にリリースしましたね! さて、Java9といえばやはり気になるのはjigsawによるモジュール機能です。モジュールの使い方までは良く見ますが、jlinkが個人的には気になってたので試した結果をまとめました。 はじめに Jigsawに関してですが少なくとも現時点では、fat-jarやgo言語のようなシングルバイナリを代替するようなことは単独ではできません。 ただ、モジュールとjlinkを使うことでアプリケーションを含んだ配布用のJVMを生成することが可能で、今回はそれについての説明になります。 モジュールで公開範囲の改善や依存の早期発見ができるようになったことは特に触れないので、その辺はこの記事とかを参考にされると良いと思います。 コードの準備 まずは、コードの準備です。 下記のような感じでアプリからライブラリが三階層で呼ばれてるようなサ

    JDK9のモジュールとjlinkでアプリ配布向けのJVMを作る - Qiita
  • HotSpot JavaVM の SIMD 最適化を効かせる方法 - Qiita

    HotSpot JavaVM のベクトル化変換 最近の HotSpot JavaVM はスカラー演算の繰り返し処理をベクトル化し SIMD 命令に変換する最適化を行っています (SIMD とは何ぞやという話は後半参照)。実際に最適化が効くコードで試してみたところ 1.5~2.8 倍程度の速度向上が見られたので、大量の演算処理を行う (GPGPU に頼らない) Java ライブラリでうまく使うことが出来れば有効な最適化手段になるかもしれません。 HotSpot の SIMD 最適化は Superword-Level Parallelism (SLP) に基づいています (以降この最適化は SLP と呼びます)。元々この論文は時代を反映して SIMD 未対応の画像・音声処理をコンパイラやランタイムのレイヤーで SIMD を利用する命令に変換することを目的としていましたが、これは SIMD 命令

    HotSpot JavaVM の SIMD 最適化を効かせる方法 - Qiita
  • Apache Ignite新メモリアーキテクチャ

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog シュティフ ロマン(データプラットフォーム) Apache Igniteコミッター @rshtykh はじめに 近頃、急激に増量していくデータはもはやタイムリー且つ正確なデータ処理を困難にする。そのような中で、複雑なETLを無くしてコストを削減でき迅速なデータ処理の可能性を実証するインメモリコンピューティング技術が注目されている。例えば、2015年からスタートしたIn-Memory Computing Summitだが、年1回の少人数イベントから、1年にインメモリシステムの開発者と利用者を2回集めるイベントまで発展してきた。 インメモリコンピューティングプラットフォーム(データベースシステム)では、なるべくメモリ上で高速なデータ処

    Apache Ignite新メモリアーキテクチャ
  • メニコア環境におけるJavaコンテナのパフォーマンス低下 - Qiita

    2018/04/08追記: まとめにJava10に関する記載を追加しました。 2017/06/02追記: 調査内容をまとめて記載を大幅に更新しました。 2017/06/01追記: 記事の最後に「JDK8/9以降の問題の取り組み」を追加しました。OpenJDK8の8u121.b34、8u131.b06で対処済みのようです(当に修正されているかは別途確認する予定)。 どちらの対処版も2017年以降にリリースされているため、頻繁にJDK/JREを更新してない場合は確認しておくとよいです。 まとめ (Java10以降) Java10では、正式にDockerコンテナをサポートするようになりました。Dockerコンテナ上のJavaプログラムはDockerコンテナで設定したCPU、メモリ等のリソース設定を把握できるようになったため、この記事で書いているメニコア問題は解消します。 Java10にDoc

    メニコア環境におけるJavaコンテナのパフォーマンス低下 - Qiita
  • Vectorization in HotSpot JVM

  • JVMはそんなに重くない | POSTD

    Clojureに反対する大きな理由がJVMです。この役立たずは重いですからね。 これは、数週間前に ZA TechSlackで見た投稿です。休暇中にClojureの話題を何件か見たのですが、投稿者はJVMについても繰り返し言及していました。 私はこの投稿について Slack上で少しつぶやいていました が、もっと広く理解され議論されるように、稿を書くことを決めました。 背景 以前は、私もJVMは重いと思っていました。2000年代の初めにJVMとPHPと比べていた頃の話です。当時は、.NETやColdFusionなど、別の重い製品が他にもありました。また、PerlPythonという軽めの製品もありましたが、私はWindowsを使っていたのでActivePerlやActivePythonはやはり少し重めでした。 私が初めてJVMに対する“恐れ”を克服したのは、小規模な製品アプリを、JRu

    JVMはそんなに重くない | POSTD
  • メモリリーク、デッドロック、リダイレクトループ、JVMクラッシュ...バグだらけのWebアプリケーションを使ってバグを理解する - Qiita

    メモリリーク、デッドロック、リダイレクトループ、JVMクラッシュ...バグだらけのWebアプリケーションを使ってバグを理解するJavaバグ脆弱性トラブルシューティングjconsole 概要 Webアプリケーションの開発や保守をしていると、いろいろなバグに遭遇します。メモリリーク、デッドロック、リダイレクトループ、JVMクラッシュ等々、バグは様々です。こういったバグは、実際にコードを書いて、実行・再現させてツールで解析してみると理解が深まります。 ということで、いろいろなバグを実装したWebアプリケーションをつくってみました。現時点では、以下を簡単に再現できます。 メモリリーク (Javaヒープ領域) メモリリーク (Permanent領域) メモリリーク (Cヒープ領域) デッドロック (Java) デッドロック (SQL) 完了しないプロセスの待機 無限ループ リダイレクトループ JVM

    メモリリーク、デッドロック、リダイレクトループ、JVMクラッシュ...バグだらけのWebアプリケーションを使ってバグを理解する - Qiita
  • JVMのチューニング - ITエンジニアとして生きる

    前回、JVMとGCのしくみ - ITエンジニアとして生きるでJVMとGCのしくみについて書いた。 今回はその続きということでJVMのチューニングについて書きたいと思う。 JVMチューニングって -Xms ・・・ ヒープ全体(New領域+Old領域)の初期値 -Xmx ・・・ ヒープ全体(New領域+Old領域)の最大値 くらいしか話題に上がらないし意識しないことが多い(気がする)。 でもホントはこれだけではダメで、前回のようにPermanent領域、New領域、Old領域を意識したチューニングが必要になる。 VMチューニングを考えるその前に・・・チューニングの話をする前にまずVMの起動モードについて話したいと思う。 VMには大きく以下2つの起動モードがあり、それぞれ以下のような特徴を持つ。 ◆クライアントVMモード 起動時間を短縮し、メモリサイズを縮小するように調整されている。 VM起動時

    JVMのチューニング - ITエンジニアとして生きる
  • JVMとGCのしくみ - ITエンジニアとして生きる

    先日職場でJVMの話をしてた。 ちょうどいい機会だからちょっとまとめたいと思う。 JVMの構成まずはJVMの構成について。JVMには3つの領域が存在する。 Permanent領域(非ヒープ領域) New領域(ヒープ領域) Old領域(ヒープ領域) Permanent領域にはJVMにロードされたクラスやメソッドの情報、New領域にはインスタンス化されたオブジェクトの情報、Old領域には寿命の長いオブジェクトの情報が管理される。(「寿命の長い」については後述のScavenge GCを参照。) Permanent領域は非ヒープ領域、New領域とOld領域はヒープ領域となる。 非ヒープ領域には基的にGCは走らず、JVM起動時に静的な情報が管理される。(※) 一方、ヒープ領域はインスタンス化されたオブジェクト情報といった動的な情報が管理され、GC対象となる。 ※ユーザ定義のクラスローダーが存在する

    JVMとGCのしくみ - ITエンジニアとして生きる
  • try { return } finally {} | POSTD

    class Test { public int aaa() { int x = 1; try { return ++x; } catch (Exception e) { } finally { ++x; } return x; } public static void main(String[] args) { Test t = new Test(); int y = t.aaa(); System.out.println(y); } } 上の質問に回答する前に、次の問題には答えられるでしょうか? try ブロック内に return 文がある場合、 finally ブロックは return の実行時に処理されるのでしょうか。 finally が実行されるなら、いかにして return と finally の両方の実行が実現するのでしょうか。 もし答えが分からなければ、どうぞこのまま読み進め

    try { return } finally {} | POSTD
  • Self-linking and Latency + Life of a Twitter jvm engineer