Skip to content

Release v0.24.0
Compare
Choose a tag to compare
@carl-mastrangelo carl-mastrangelo released this 24 May 10:49
· 160 commits to master since this release
v0.24.0
This tag was signed with the committer’s verified signature.
carl-mastrangelo Carl Mastrangelo
GPG key ID: 3AD93C3C677A106E
Learn about vigilant mode.
f116557

New Features

  • Added an examples subproject which shows how to serve the TraceUI over the web. This uses Perfetto which can help in reducing the large jar size that the traceviewer subproject uses. ( c1f3f63 )
  • TaskCloseable is now stabilized ( ac72491 )
  • Added JPMS Support (Java 9 Modules) via Automatic-Module-Name ( 6a91457 )

Behavior Changes

Class Loading

  • Avoid using java.util.Logger if possible. This reduces the class load time (18ms -> 9ms) and memory usage. ( be6ddaf , cf43b05 )
  • Logging can be re-enabled by setting the system property io.perfmark.Perfmark.debug=true, which is useful for diagnosing failures to load.
  • Only a single implementation of Generator and MarkHolderProvider are loaded, rather than loading all available implementations.
  • PerfMark is more cautious about failing during static initialization. It now safely disables itself if any problems are encountered.

Memory Usage

  • PerfMark keeps all trace info in a thread-local buffer, with the expectation that the data would be read asynchronously. Because it was
    not clear if/when the data would read later, the life time of the trace data was limitted to the lifetime of the thread. When the
    thread exited, the next call to read the trace data would consume and delete it. Since it was still unclear how often this would be
    consumed, every new thread created would also delete the data of any other dead threads.

    This has been changed to keep the trace data around (but not the thread) for as long as there is available memory (via a SoftReference).
    If a thread is dead, and a major GC cycle happens, the trace data will be cleared. This also means that for applications which do not
    have major GC's frequently, the memory usage will appear to be higher. The purpose of this change is to ensure the trace data for
    recently deceased threads can be consumed, rather than it being removed before it could be read. ( b6d650f )

Documentation

  • Improved the documentation in several places, describing key concepts in the Javadocs ( 4ea4529 , e248396)

Bug Fixes

  • Fixed a race condition where the Java6 storage was missing a synchronized statement ( 991b34a )

  • Fixed JSON output not being minified for TraceViewer ( 4fbecdf ).

Assets 2