どうも、趣味でOpenJDKのコミッタをしてます。 とあるブログを読んでいたら気になる点があったので検証してみました。 JITと暖気 Javaプロセスはアプリケーションを動かしながら必要に応じてバックグラウンドでバイトコードをネイティブコードにコンパイルします。このコンパイル時にはCPUリソースを使用します。 コンパイルにはいくつかのレベルがありますが、コンパイルされる前やレベルの低いコンパイルのコードはCPUのリソース効率が悪かったり、アプリケーションの処理中にコンパイルが実行されるとCPUリソースを奪いあったりなどが問題になります。 そのため、Java のアプリケーションで性能を気にする要件がある場合、本番に近いリクエストを投げてコードをJITコンパイルする事があります。これをよく暖気と言います。これにより本番のリクエストが来る前にコードを最適化し、よりCPUリソース効率の高いコードで
In this tutorial, we will talk about how different Java Garbage Collectors work and what you can expect from them. This will give us the necessary background to start tuning the garbage collection algorithm of your choice. Before going into Java Garbage Collection tuning we need to understand two things. First of all, how garbage collection works in theory and how it works in the system we are goi
メリークリスマス!本記事は Emacs Advent Calendar 2019 の25日目の記事です。 まずはこちらをご覧ください。 java コマンドと同様、Emacs でも "Hello, World!" を出力していますね。 HelloWorld.java を書き換えてコンパイルしたあとも、java コマンドの結果と同じ文字列を出力しています。 これはどういうことかというと、 純度 100% Emacs Lisp で .class ファイルを解析・実行しています。 つまり Emacs が JVM となった瞬間です。おめでとうございます 🎉 当然ながら JVM 全てをカバーできているわけではなく、基本的な部分だけを実装してあります。 今後も開発は続くかもしれないし、続かないかもしれません。 本記事の概要 開発に至った経緯 開発のおはなし 1. .class ファイルの解析 1-1.
rchaser53noMacBook-Pro:rj rchaser53$ javap -v java/io/PrintStream Classfile jar:file:/Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/jre/lib/rt.jar!/java/io/PrintStream.class Last modified 2017/07/21; size 9048 bytes MD5 checksum f62b2b102171bb9cd2cefa5efcf0e487 Compiled from "PrintStream.java" public class java.io.PrintStream extends java.io.FilterOutputStream implements java.lan
2019/11/23に開催されたJJUG CCC 2019 Fallでの登壇資料です
ヌーラボでScalaを書くRubyistの谷本です。ヌーラボでは、Backlogの開発を担当しており、最近ではBacklogをJavaからScala / Play Frameworkに移行するプロジェクトのメンバーでした。 BacklogのPlay化プロジェクトでは、OutOfMemorryError(以下、OOM)の発生やCPU使用率とロードアベレージが上がったままという、Java Virtual Machine(以下、JVM)上で動くBacklogのパフォーマンスに関する問題に対処すべく、何度かHeap/Thread dumpを見る機会がありました。 私がPlay化プロジェクトで取り組んだパフォーマンス改善の知見や経験をもとに、本記事では「JVMで起こったパフォーマンスの問題の切り分け方」についてお届けします。 はじめに 本番環境でしばらく動かしていると、コード自体は正しく実行できるけ
最近 JVM のヒープ領域とパラメータ、そしてコンテナの関係について調べてました。 案外まとまった情報が少なかったので簡単にまとめました。 Java のヒープサイズを設定 まずは Java のヒープサイズについて簡単なおさらいです。 本番環境で Java アプリケーションを運用する上で、JVM のヒープサイズを決定するのは非常に大事なポイントです。 ヒープ領域の最大サイズを大きくすればガベージコレクション (GC) の回数は減らすことができますが、 必要以上に大きくしすぎると無駄にリソースを消費したり、OOM killer で OS にプロセスを終了させられます。 JVM が使用できるヒープサイズは、Java API の Runtime.getRuntime().maxMemory() で確認できます。 また java の起動オプションに -XX:+PrintFlagsFinal オプショ
2019年7月17日、kafka.apache.jpが主催するイベント「Apache Kafka Meetup Japan #7」がLINE株式会社にて開催されました。分散ストリーミングプラットフォーム「Apache Kafka」に関するナレッジや最新情報を共有する本イベント。今回は4人のエンジニアが、自身や自社における知見を語りました。プレゼンテーション「Kafka Broker performance degradation by mysterious JVM pause」に登壇したのは、LINE株式会社の河村勇人氏。ある日Kafkaに起こった突然のパフォーマンス低下とその原因について、解決までの軌跡を語りました。講演資料はこちら Apache Kafkaのパフォーマンス低下とその原因 河村勇人氏:よろしくお願いします。最初に自己紹介をします。河村勇人といいます。 LINEで全社向けの
関ジャバ'19 7月度 - connpass https://kanjava.connpass.com/event/134133/ 登壇資料
"JVM Anatomy Quarks" is the on-going mini-post series, where every post is describing some elementary piece of knowledge about JVM. The name underlines the fact that the single post cannot be taken in isolation, and most pieces described here are going to readily interact with each other. The post should take about 5-10 minutes to read. As such, it goes deep for only a single topic, a single test,
The JVM can be a complex beast. Thankfully, much of that complexity is under the hood, and we as application developers and deployers often don't have to worry about it too much. With the rise of container-based deployment strategies, one area of complexity that needs some attention is the JVM's memory footprint. Two kinds of memory The JVM divides its memory into two main categories: heap memory
2018年9月17日から18日にかけて、日本最大のPythonの祭典、PyCon JP 2018が開催されました。「ひろがるPython」をキャッチコピーに、日本だけでなく世界各地からPythonエンジニアたちが一堂に会し、様々な知見を共有します。プレゼンテーション「JVM上で動くPython3処理系cafebabepyの実装詳解 」に登壇したのは株式会社エフ・コード澁谷典明氏。講演資料はこちら写真提供:PyCon JP JVM上で動くPython3処理系cafebabepyの実装詳解 澁谷典明氏:では、cafebabepyというJVM上で動くPython3処理系の実装詳解というかたちで話させていただきます。 注意! 言語処理系の実装詳解というだいぶ無茶なことをやるので、スライドが多めです。気になったところがあれば、個別に質問したり、あとでスライドを公開するので見てください。 こんなニッチ
When I run the following Java program, which consumes all free memory with artificial data structures, something interesting happens. Something very similar happens to all real applications: https://gist.github.com/CodingFabian/8708393 [node04] ~ ➜ jdk1.7.0_51/bin/java -Xms31g -Xmx31g -Xmn50m Memory Total Memory (in bytes): 33279705088 Free Memory (in bytes): 33278908064 Max Memory (in bytes): 332
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く