1 / 43

Java Flight Recorder Behind the Scenes

Java Flight Recorder Behind the Scenes. Staffan Larsen Java SE Serviceability Architect staffan.larsen@oracle.com @ stalar. Java Flight Recorder. Quick Glance. Tracer and Profiler Non-intrusive Built into the JVM itself On-demand profiling After -the-fact capture and analysis

chance
Télécharger la présentation

Java Flight Recorder Behind the Scenes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Java Flight Recorder Behind the Scenes Staffan LarsenJava SE Serviceability Architect staffan.larsen@oracle.com @stalar

  2. Java Flight Recorder Quick Glance • Tracer and Profiler • Non-intrusive • Built into the JVM itself • On-demand profiling • After-the-fact capture and analysis • First released in 7u40 Photograph by Jeffrey Milstein http://butdoesitfloat.com/In-the-presence-of-massive-gravitational-fields-this-perfect

  3. Tracer and Profiler • Captures both JVM and application data • Garbage Collections • Synchronization • Compiler • CPU Usage • Exceptions • I/O • Sampling-based profiler • Very low overhead • Accurate data

  4. Non-intrusive • Typical overhead in benchmarks: 3-5% (!) • Often not noticeable in typical production environments • Turn on and off in runtime • Information already available in the JVM • Zero extra cost Photograph: Andrew Rivett http://www.flickr.com/photos/veggiefrog/3435380297/

  5. Built into the JVM itself • Core of JFR is inside the JVM • Can easily interact with other JVM subsystems • Optimized C++ code • Supporting functionality written in Java

  6. On-demand profiling • Start from Java Mission Control • Or from the command line • Easily configure the amount of information to capture • For a profile, a higher overhead can be acceptable • When done, no overhead • Analyze the recording with a powerful GUI afterwards

  7. After-the fact analysis • In its default mode, very low overhead • Designed to be always-on • Uses circular buffers to store data • In-memory or on-disk • When an SLA breach is detected, dump the current buffers • Dump will have information leading up to the problem

  8. Enough Talking • Demo!

  9. Agenda • Overview of JFR • Demo! • Configuration topics • Implementation details

  10. Configuration • Enable -XX:+UnlockCommercialFeatures -XX:+FlightRecorder • Start -XX:StartFlightRecording=filename=<path>,duration=<time> • Alternate jcmd <pid> JFR.start filename=<path> duration=<time>

  11. Advanced Configuration • Per recording • Maxage, maxsize • In-memory, on-disk • Globals • -XX:FlightRecorderOptions • Repository path • Max stacktrace length

  12. Troubleshooting • -XX:FlightRecorderOptions=loglevel=[ERROR, WARNING, INFO, DEBUG, TRACE]

  13. How is it built? High-level JMX Java Events • Information gathering • Instrumentation calls all over the JVM • Application information via Java API • Collected in Thread Local buffers • Moved to global buffers => to disk • Managed via JMX • Binary, proprietary file format JVM Compiler GC Runtime Threads JFR Global Disk

  14. “Everything is an Event” Events • Event record • Event ID • Thread ID • Start Time • End Time • Stacktrace ID • Payload: int, long, double, string, class, thread,… • Event Description • Name, Description text, • For each payload item: name, type, description, content type Event ID Thread ID Start End Stacktrace ID Payload

  15. Event types • Duration Events • Timing for something • Ex: GC • Instant Events • Single point in time • Ex: Thread starts • Requestable Events • Happens with a specified frequency • Ex: CPU Usage every second

  16. Content Type • Describes the semantics of a value • Bytes • Percentage • Address • … • Used to correctly display the value in the UI

  17. Self describing file format • Everything needed to parse an event is included in the file • If the VM adds a new event, there is no need to update the UI parser • Of course, the information will not be part of any of the specialized UIs, but the raw data is still there and can be analyzed and correlated • Single file, no dependencies … Header Events Event definitions

  18. Event definition in Hotspot <event id="ThreadSleep" path="java/thread_sleep"label="Java Thread Sleep”...> <value field="time" type="MILLIS" label="Sleep Time"/></event> • XML definitions are processed into C++ classes

  19. Event emission in Hotspot JVM_Sleep(int millis) { EventThreadSleep event; ... // actual sleep happens here event.set_time(millis); event.commit(); } • Done! Data is now available in JFR

  20. Thread Park <event id="ThreadPark" path="java/thread_park” label="Java Thread Park”has_thread="true" has_stacktrace="true" is_instant="false"> <value type="CLASS" field="klass" label="Class Parked On"/> <value type="MILLIS" field="timeout" label="Park Timeout"/> <value type="ADDRESS" field="address" label="Address of Object Parked”/> </event>

  21. UnsafePark(jbooleanisAbsolute, jlong time) EventThreadParkevent; JavaThreadParkedState jtps(thread, time != 0); thread->parker()->park(isAbsolute != 0, time); if (event.should_commit()) { oop obj = thread->current_park_blocker(); event.set_klass(obj ? obj->klass() : NULL); event.set_timeout(time); event.set_address(obj ? (TYPE_ADDRESS)obj : 0); event.commit(); }

  22. Screenshot Event Graph

  23. Screenshot Event Details

  24. Buffers • (pretty picture of threads->global (pool)->disk) • “Circular” • Designed for low contention Thread Local Buffer Global Buffer Disk Chunk Repository Java JVM

  25. Recordings • A recording can specify exactly which events to enable • XXX events with Y settings each • But: we ship two preconfigured settings • “default”: provides as much information as possible while keeping overhead to a minimum • “profile”: has more information, but also higher overhead • You can configure your own favorites in Mission Control

  26. Filtering data • Enable/disable • Thresholds • Frequency

  27. Many simultaneous recording sessions • This works great • Each session can have its own settings • Caveat: If there are multiple sessions all of them get the union of the enabled events • Ex: If event A is enabled in on recording, all recordings will see event A • Ex: If

  28. Designing for long-running recordings in a dynamic runtime • Can’t leak memory • Can’t aggregate information eternally • Can’t keep references that prohibits class unloading • Dynamic Runtime • Classes can come and go • Threads can come and go • Solution: checkpoints, constant pools

  29. Referencing classes, threads, stacktraces • To keep size of event small, these are referenced by an ID • “Constant pool” • Ex: First time a class is referenced, it is assigned an ID and tagged • When a checkpoint is created, information for all tagged classes is written to the file • Also, when a tagged class is unloaded, its information is written out

  30. Problem: Many events reference classes • If every event contained the class name, we would waste lots of space • Solution: Use an ID number to refer to the class • Problem: How to look up the ID? • Solution: Have a lookup table in the recording. Event ID 17 class 4711 table.get(4711) -> “java.lang.Integer” count 2

  31. When do we write the lookup table? • Problem: classes can be unloaded at any time • Can’t wait until the recording ends – class may not be around • Solution: write out IDs when classes are unloaded

  32. Optimizing the size of the lookup table • Problem: many classes are loaded, not all are referenced in events, we want to save space • Solution: when a class is referenced, it is also “tagged” • Write only tagged classes to the lookup table

  33. Leaking data • Problem: over time many classes will be tagged, the size of the lookup table will increase • Solution: reset the tags each time a lookup table is written to disk • A recording file may contain many lookup table, each one is only valid for the data immediately preceding it … data lookup data lookup

  34. Checkpoints • At regular intervals, a “checkpoint” is created in the recording • Has all the metadata needed to parse the recording since the last checkpoint • Ex: An event references a class via a class id

  35. Optimizations • Fast Timestamping • Stacktraces

  36. Benchmarks • ?

  37. More information • Whitepaper: • User Guide:

  38. Differences vsJRockit • I/O: File paths, socket address • Exceptions • Reverse call trace view in MC • Deeper (configurable) stacktraces • Internal JVM differences: GC • Easier configuration in MC

  39. Take-away -XX:+UnlockCommercialFeatures-XX:+FlightRecorder

  40. Q&A @stalar staffan.larsen@oracle.com serviceability-dev@openjdk.java.net

  41. The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract.It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

More Related