Crucible is a language-agnostic library for performing forward symbolic execution of imperative programs. It provides a collection of data-structures and APIs for expressing programs as control-flow graphs. Programs expressed as CFGs in this way can be automatically explored by the symbolic execution engine. In addition, new data types and operations can be added to the symbolic simulator by imple
The bin directory contains a set of shell scripts to combine common perf / dtrace perations with creating the map file. create-java-perf-map.sh <pid> <options*> takes a PID and options. It knows where to find libraries relative to the bin directory. perf-java-top <pid> <perf-top-options> takes a PID and additional options to pass to perf top. Uses the agent to create a new /tmp/perf-<pid>.map and
Currently there are several tools available to analyse your application performance and show the results. Traditionally these results are either shown in some kind of table form, either flat or as a tree view. Flame graphs are relatively new and take a new angle to show the results. Furthermore, flame graphs can be generated on various levels; tooling hooking into the JVM, but also on (Linux / Mac
Hi everyone. One of the Tooling team focus lately has been improvement of the contribution process to sbt. Another thing we’ve been thinking is the performance of sbt. Combining these themes together, I’ve been looking into how guys like Jason Zaugg and Johannes Rudolph profile JVM applications, and this post is my findings. The techniques described here should be applicable to both Java and Scala
Profiling JVM Applications in Production Sasha Goldshtein CTO, Sela Group @goldshtn github.com/goldshtn https://s.sashag.net/srecon0318 Workshop Introduction • Mission: Apply modern, low-overhead, production-ready tools to monitor and improve JVM application performance on Linux • Objectives: qIdentifying overloaded resources qProfiling for CPU bottlenecks qVisualizing and exploring stack traces u
この記事は TIS Advent Calendar 2017 16 日目の記事です。 Clojure を仕事で使い始めてから三年が経ちました。未だに学びが多いですが、年数的には中堅 Clojurian と言える域に達してしまったので、自分なりの Clojure 観を整理したいと思い立ちました。自分にとって Clojure の最大の魅力は高速開発です。そしてそれは Clojure 自体の習熟難度と秤にかけても十分魅力的だという話を書きます。 どちらかと言えば Clojure 勉強し始めで、このまま進んでいいか迷っている人向けの内容です。 この記事は2017年時点での内容です。更新版・続編 → キメる Clojure チーム開発 そもそも Clojure とは 時は 2053 年、Skynet が人類を虐げる世界。エージェント Meier は Skynet のログにアクセスすることに成功し、S
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では、
The “Java Decompiler project” aims to develop tools in order to decompile and analyze Java 5 “byte code” and the later versions. JD-GUI is a standalone graphical utility that displays Java source codes of “.class” files. You can browse the reconstructed source code with the JD-GUI for instant access to methods and fields. JD-Eclipse is a plug-in for the Eclipse platform. It allows you to display a
メモリリーク、デッドロック、リダイレクトループ、JVMクラッシュ...バグだらけのWebアプリケーションを使ってバグを理解するJavaバグ脆弱性トラブルシューティングjconsole 概要 Webアプリケーションの開発や保守をしていると、いろいろなバグに遭遇します。メモリリーク、デッドロック、リダイレクトループ、JVMクラッシュ等々、バグは様々です。こういったバグは、実際にコードを書いて、実行・再現させてツールで解析してみると理解が深まります。 ということで、いろいろなバグを実装したWebアプリケーションをつくってみました。現時点では、以下を簡単に再現できます。 メモリリーク (Javaヒープ領域) メモリリーク (Permanent領域) メモリリーク (Cヒープ領域) デッドロック (Java) デッドロック (SQL) 完了しないプロセスの待機 無限ループ リダイレクトループ JVM
Java7 Update4 (java7u4) で正式サポートされたG1GC(ガベージ・ファーストGC)ですが、Java9ではデフォルトGCになることが確定しています。 参考: JEP248 またG1GCは、CMS GCを長期的に置き換えるものとして計画されています。 そこで、どのようなアルゴリズムなのか知っておいたほうが良さそうなので調査しました。 G1GCが向いているケース G1GCが向いているのは下記の環境です。 ヒープサイズが大きな環境(6GB以上) 一時停止可能時間がシビア(0.5sec未満) Oracleの 9 ガベージファースト・ガベージ・コレクタによると、CMS GCもしくはParallel GCを使っていて次のいずれかに該当したらG1GCへの切り替えを検討しましょうとのことです。 Javaヒープの50%超がライブ・データ(≒必要なデータ)で占められている。 オブジェクトの
LLJVM provides a set of tools and libraries for running comparatively low level languages (such as C) on the JVM. The C to JVM bytecode compilation provided by LLJVM involves several steps. Source code is first compiled to LLVM intermediate representation (IR) by a frontend such as llvm-gcc or clang. LLVM IR is then translated to Jasmin assembly code, linked against other Java classes, and then as
Recent posts: 29 Oct 2024 » AI Flame Graphs 22 Jul 2024 » No More Blue Fridays 24 Mar 2024 » Linux Crisis Tools 17 Mar 2024 » The Return of the Frame Pointers 10 Mar 2024 » eBPF Documentary 28 Apr 2023 » eBPF Observability Tools Are Not Security Tools 01 Mar 2023 » USENIX SREcon APAC 2022: Computing Performance: What's on the Horizon 17 Feb 2023 » USENIX SREcon APAC 2023: CFP 02 May 2022 » Brendan
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Java CPU Flame Graphs
