https://github.com/jakewins/jaa

Actionable memory analysis for JVM languages
https://github.com/jakewins/jaa

java jvm jvm-performance kotlin openjdk scala

Last synced: 25 days ago
JSON representation

Actionable memory analysis for JVM languages

• Host: GitHub
• URL: https://github.com/jakewins/jaa
• Owner: jakewins
• License: gpl-3.0
• Created: 2017-12-27T22:45:03.000Z (almost 7 years ago)
• Default Branch: master
• Last Pushed: 2017-12-29T22:45:12.000Z (almost 7 years ago)
• Last Synced: 2024-09-30T13:05:26.806Z (about 1 month ago)
• Topics: java, jvm, jvm-performance, kotlin, openjdk, scala
• Language: Java
• Homepage:
• Size: 99.6 KB
• Stars: 17
• Watchers: 3
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

        
[![Build Status](https://travis-ci.org/jakewins/jaa.svg?branch=master)](https://travis-ci.org/jakewins/jaa)

# JVM Allocation Analyzer, JAA

JVM allocation analysis that filters out allocations HotSpot optimizes out.

This gives you allocation reports that are actionable, meaning if you address the top allocations in the report, 

you'll make a good dent in actual production heap usage.

## Minimum viable snippet

Add dependency:

    

      com.jakewins

      jaa

      1.1.0

    

    

Write analysis case:

    public class SimpleExample {

    

        public static void main(String ... argv) throws IOException {

            new Jaa(new Options.Builder()

                    .include(SimpleExample.class)

                    .withReportFolder(Paths.get("./target/allocation-reports"))

                    .build())

                    .run();

        }

    

        @AllocationAnalysis

        public void simple() {

            System.out.println("Hello, world!");

        }

    }

See [examples](src/main/java/jaa/examples) for more running code.

## Rationale

There are many ways to analyze allocations on the JVM - object counting, TLAB acquisition tracking, etc. 

If you want an exact account of what was allocated and where, instrumenting bytecode is the way to go.

However, instrumenting byte code to track each allocated object makes it impossible for the JVM to perform standard optimizations.

The reports become filled with allocations that the JVM would optimize into stack allocations or remove altogether under normal operation.

The end result being that the reports are not actionable - if you fix the worst allocation points from an instrumentation-based report,

you're likely to make no difference to your programs performance, since you're just manually doing HotSpots job.

JAA analyses memory in three steps:

1. Execute the test without instrumentation with `-XX:+PrintEliminateAllocations`. Use the output from this to build an index of allocations the JVM removes already.

2. Execute the test with instrumentation

3. Filter the report from (2) with the data from (1)

This gives you a report of allocation points the JVM does not move to the stack or remove, substantially improving the usefulness of the analysis.

## Limitations

- Java 8 only, for now

- OS X users need to manually acquire a `fastdebug` build of OpenJDK (consider +1 [here](https://github.com/AdoptOpenJDK/openjdk-build/issues/146) to solve this)

- Ambiguity in OpenJDK debug output could lead to reports excluding the wrong thing. OpenJDK only outputs the class names, not the fully qualified names, so two allocation points allocating the exact same object could end up tricking JAA to eliminate the wrong allocation. 

## License

GPLv3