JVM勉強会（開発編）を開催しました - 株式会社ヘンリー エンジニアブログ
こんにちは、SREの戸田です。本日はJVM勉強会（運用編）に続けて開催したJVM勉強会（開発編）の一部を公開します。 図1 勉強会はやっぱりGoogle Meetでオンライン開催しました システムプロパティ システムプロパティは環境変数のように、プログラムの挙動を変えるために利用することが多いです。例えばOpenJDKそのものでも Integer.valueOf() で値をどの程度キャッシュするか*1を設定するためにシステムプロパティを使っています。 他にも user.language あたりはよく知られていますし、標準で提供されるシステムプロパティも多数あります。しかし製品コードから直接参照することは基本ないと思っていて、 File.pathSeparator などの提供されたAPIを使うことが望ましいでしょう。またシステムプロパティは動的に変更することも可能ですが、システムプロパティを
Tuning glibc Memory Behavior | Heroku Dev Center
Application maintainers may tune application performance and memory use by adjusting the MALLOC_ARENA_MAX environment variable. Recent versions of glibc use multiple memory pools that malloc can allocate memory from. Especially for threaded programs, using multiple memory pools can speed up memory allocation (be reducing locking) and improve overall performance. See this article for details on the
On the Performance of User-Mode Threads and Coroutines – Inside.java
Discussions of coroutines and user-mode threads — like Project Loom’s virtual threads or Go’s goroutines — frequently turn to the subject of performance. The question I’ll try answering here is, how do user-mode threads offer better application performance than OS threads? One common assumption is that this has to do with task-switching costs, and that the performance benefit of user-mode threads
GraalVMはどれだけ遅いか - きしだのHatena
GraalVM流行ってますね。 そして、多くの人はGraalをAOTとして使うnative-imageのことだけをGraalVMと言ってたりします。 ご安心を。このエントリではGraalをJITとして使うHotSpotモードとGraalをAOTとして使うnative-imageの両方が遅いという話です。 GraalVMは速い、と言われてますが、残念ながらHotSpotモードでC2より速い結果を手元では出せていません。 公式ブログでは1.7倍から5倍速くなると書いてますけど、手元では再現できてません。 Under the hood of GraalVM JIT optimizations - graalvm - Medium native-imageは速い、というのはよくありますが、これはネイティブ化によりJVMの起動時間や最適化の時間、最適化されずに動く時間が省略されるので起動が速い、とい
メニコア環境におけるJavaコンテナのパフォーマンス低下 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 2018/04/08追記： まとめにJava10に関する記載を追加しました。 2017/06/02追記： 調査内容をまとめて記載を大幅に更新しました。 2017/06/01追記： 記事の最後に「JDK8/9以降の本問題の取り組み」を追加しました。OpenJDK8の8u121.b34、8u131.b06で対処済みのようです（本当に修正されているかは別途確認する予定）。 どちらの対処版も2017年以降にリリースされているため、頻繁にJDK/JREを更新してない場合は確認しておくとよいです。 まとめ (Java10以降) Java10では、正
Java で最速の乱数生成器を目指す: (3) ガンマ分布に従う乱数
TL;DR: ガンマ分布に従う乱数生成器を Java で実装し、Commons Math の実装と比較して 最大で約 16 倍 (任意の形状パラメータの乱数を生成する場合) の速度効率を達成しましたよ、というお話です。 (Header image: Mundhenk at en.wikipedia) ガンマ分布に従う乱数生成の実装方法Permalink これまで 正規分布に従う乱数生成、指数分布に従う乱数生成 をそれぞれ Java で実装してきましたが、今回はガンマ分布に従う乱数生成を Java で実装してみます。 ガンマ分布 は、形状パラメータ k>0 と スケールパラメータ θ>0 (もしくは形状パラメータ α=k と比率パラメータ β=1/θ) の 2 つのパラメータを持ち、その確率密度関数は次の式で表されます。 f(x)=xk−1e−x/θΓ(k)θk ガンマ分布の形状パラメータ
Optimizing JavaというJavaパフォーマンス系の書籍が面白そう - 谷本 心 in せろ部屋
急激な冷え込みのせいで「寒い！」というつぶやきがTLに散見されるこの頃ですが、皆さんお風邪など召していらっしゃらないでしょうか。 否応なしに寒いという言葉に反応してしまう、けなげなエンジニアの [twitter:@cero_t] です。 このエントリーは Java Advent Calendar 2016 の8日目です。 昨日は [twitter:@haruo31] さんの「Java Stream APIでハマったこと」で、 明日は [twitter:@deaf_tadashi] さんの「マイクロベンチマークツール、JMHについて」でした。 今日のエントリーでは、Javaのパフォーマンス系書籍を紹介したいと思います。 Optimizing Java - O’Reilly Media URLを見るにつけ、あのオライリー様のサイトですら拡張子が由緒正しい .do なのですから、日本のSIerが
Kotlin vs Java: Compilation speed
If you convert an app from Java to Kotlin, will it take longer to compile? This is part 3 in a series of articles on Kotlin. Part 1 discussed converting an Android app from Java to Kotlin, and part 2 contains my thoughts on the Kotlin language. In an earlier article, I discussed converting an Android app from Java to 100% Kotlin. The Kotlin codebase was smaller and more maintainable than it’s Java
Scala 2.12 における Java 8 への移行、対応について - ろじかるんるんものがたり
お仕事は相変わらずないので結構ピンチです。 Scala 遅いといわれてるけど Java6 切り捨てる 2.12 からは改善されるから見てろよ見てろよ～～（そんなに劇的には改善されません）— りりかるろじかるのお気持ち (@lyrical_logical) August 19, 2016 軽い気持ちでツイートしたら、ちょっとだけですが RT されたり like されたりしたのでちょっとまとめます。あんまり Scala 2.12 での Java 8 対応まとめみたいな記事、国内外問わず、公式にも非公式にも（知ら）ないなあと思ったので、簡単に…ロードマップにちらっとあるくらい？ SAM サポートの追加 Java 8 のラムダ記法を支える SAM(Single Abstract Method)…という用語は古くて、正確には Functional Interfaces といったほうがいいんですが、F
Javaのテスト実行時間を62%削るvmvmを試してみた - flyhigh
概要 vmvm てのを使うと、テスト実行時間が短くなることがあるらしいので、試してみた。 結果、私の試行では早くならなかったが、早くなる人もいるかと思われ、使い方をシェアしたい。 vmvmて何？ 論文漁ってたらたまたま見つけた、 ICSE ‘14のペーパ 。すでに１年経過してる。タイトルは、”Unit Test Virtualization with VMVM”。Unit test virtualization??と思いつつも、読み進める。どうやらJavaのテスト実行時間を62%短くする、 vmvm てのを作ったらしい。62%て。 なんとも驚異的な結果。さすがICSE。 使ってみる(maven編) (antは 公式README を参照) 論文の中身はさておき、まずはチェックアウト。ビルドしてインストール。バイナリもあるのでそれにパスとおしても良い。 1 2 git clone https:
Web API サーバ負荷試験のすすめ方 – 観点を整理、負荷を試算、対象を選定 | DevelopersIO
負荷試験対策ミーティング ここでは、チームメンバーを集めて、システム要件の再確認と、バックエンドのアーキテクチャを再確認をまず行います。すなわち、「求められているもの=要件」と、「提供できるもの=アーキテクチャ」の確認です。ここの認識が揃っていないと、的はずれな負荷試験を実施してしまうことになりかねません。立場や役割にかかわらず、サービス全体として考えるべきです。 負荷試験の目的 負荷試験を行うことによって、何を示したいのか決めます。今回は、以下の目的を定めます。 サービスリリース後、想定されるピーク時のリクエストを受けた場合でも、問題なく稼働を続けられることを確認する システムのスループット限界値を確認する 負荷試験の観点 たいていのWebシステムの場合、昼夜を問わず稼働し続けるものとなるでしょう。今回例にとったシステムも24時間365日、リクエストを受け付けるものとします。この場合、観
Javaの謎のパフォーマンス劣化現象との戦い - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。アプリケーション基盤チームの横田です。 Javaの謎のパフォーマンス劣化にまつわる調査をしていたのですが、1ヶ月の苦労の末に原因がわかりましたので、報告させていただきます！ 公開後に頂いたはてなブックマークでのご指摘・社内でのタイポ・読みにくいなどの指摘を受けてたので、謹んで修正させいただきます。 修正した内容につきましては、記事の最後を参照してください。 忙しい人のためのまとめ jdk-7u4以降のjdk-7 *1 でJavaのパフォーマンスが劣化する謎の現象 CodeCacheの容量限界に近づくとJITコンパイラを停止してコンパイルしたコードを捨てる機能が原因だった 起動オプションで回避できるので、長期運用するときは -XX:-UseCodeCacheFlushing, -XX:ReservedCodeCacheSize=128m をつける 上のオプションを設定した時に、C
性能改善10事例 - Taste of Tech Topics
こんにちは、 @snuffkin です。 Acroquestでは、Elastic{ON}のような勉強会やカンファレンスに参加するだけでなく、社内向けの勉強会も開催しています。 新しい技術を調べて「使ってみた」的な発表をしたり、実際に開発の中で得られた知見を発表したり。 各自が得意分野で、様々なテーマで発表し、技術の研鑽を行っています。 私の場合、しばらく性能改善に取り組んでいたため、 その際に解決した問題からいくつか事例をフィードバックし、 性能問題を起こさないよう喚起しました。 10 performanceimprovements 性能改善10事例 from Acroquest Technology www.slideshare.net スライドでも書きましたが、特に大量に繰り返し実行される処理では、性能を意識した実装をしないと問題になりがちです。 問題があちこちに散らばると性能が大きく
jmhマイクロベンチマークツールを使ったByteBufferのバイトオーダによるパフォーマンスの違いの比較 - seraphyの日記
(ヒープおよびダイレクトバッファによるByteBufferの性能差、およびUnsafeとのパフォーマンスも比較するよ！) (とりあえず計測結果を先に知りたい人は結論を見てね！) (ファイルのシーケンシャルリードを含むダイレクトバッファの使い方やパフォーマンス比較については次の日記に書きました。) 概要 思うところあって、ヒープ上のbyte[]をラップしたByteBufferと、ダイレクトバッファを確保しているByteBufferの場合とのint型としての連続アクセスした場合のパフォーマンスの違いについて調べてみることにした。 私の認識では、ダイレクトバッファへのアクセスは非ネイティブ側(つまりJavaコード側)からのアクセスではオーバヘッドが大きいため、特殊なシチュエーション以外では遅くなってしまうため、あまり使いどころのない機能だというものだったのだが、では、その使いどころとなる「特殊な
遅いッ！遅すぎるッ！Java の正規表現のお話。 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、ミドルウェア開発チームの青木です。 先日、アプリケーションサーバーが応答を返さなくなるトラブルに遭遇しました。 今回はその時のトラブルの原因と対策の顛末についてお話しようと思います。 現象 アプリケーションサーバーが突如応答を返さなくなりました。 現象が発生したアプリケーションサーバーのスタックトレースを見ると、あるスレッドの先頭が上記のようになっていました。 "qtp258153142-514386" prio=10 tid=0x00007f40b8dbf000 nid=0x7b4e runnable [0x00007f415ccb0000] java.lang.Thread.State: RUNNABLE at java.util.regex.Pattern$Loop.match(Pattern.java:4692) at java.util.regex.Pattern$G
Javaでのnullチェックのパフォーマンス - きしだのHatena
Javaでのプログラムでは、Optionalが入ったとはいえ、nullとのつきあいは依然として重要です。 そんな中で、nullが入ってると困る処理を書くときには、nullチェックを行うほうが安全です。 そのとき、どのようにnullチェックを行うかというのが問題になります。 Java7からは、Objects.requiredNonNullというメソッドが導入されたので、このメソッドを使って、以降の処理でnullじゃないことを保証するということができます。 けど、このrequiredNonNullが遅いんじゃないかという話があるので、どう遅いのか調べてみました。 requireNonNullと同様に、値がnullだったらNullPointerExceptionを吐いて、null以外だったら素通りするという書き方のひとつに、getClassメソッドを呼び出すというものがあるので、これと比べてみま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
#渋谷java : Java の数学関数を計算速度的に極めたい
実行時におけるJVMバイトコード最適化手法
GitHub - HeapStats/heapstats: JVMTI agent and JavaFX analyzer to gather JVM runtime information for after-the-fact analysis.
パフォーマンスを意識した Java コーディング #渋谷java
