- Loading...
Page History
...
- Provide a minimal agent for instrumenting methods with flight recorder events
- Piggybacks on the flight recorder capabilities to provide :
- Provides low overhead event generation
- Cheap time stamping
- Allows subsequent enablement/disablement of generated events using normal JFR templates
(In other words, to disable an instrumentation point, no subsequent redefinition is - Clear and precise syntax
(No wildcards. Instrumentation points meant to be added with assistance from tooling, but syntax should be easy enough to be manually edited, if required.) Clear and precise syntax - Minimal overhead ( in terms of added code/generated classes
(On parity with manually added events.) - Loadable as an agent into an already running runtime
(can Can redefine classes.) - Controllable through a JMX MBean
(perhaps Perhaps simply an operation taking a new probe definition.) - Must be extremely safe out of the box
- No calling methods (avoiding halting problems) / unexpected exceptions (except possibly when converters enabled?)
- No implicit type conversions (boxing of wrapper types to primitive types ok?)
- General catch-all calls to toString(), if at all allowed, must be explicitly enabled
- Module safe - only module redefinition is making jdk.jfr readable from instrumented modules
- Built for production use
- Need to have sufficient unit testing
- Need to be tested against larger bodies of code (Oracle can help with Fusion staging and test environments etc)
- Need to support OracleJDK 8 as well as OpenJDK 11+
...
- Annotation driven generation
(optOpt-in, adds the overhead of looking for annotations in all classes, i.e. parsing all classes.) - Get it into the JDK?
(could Could potentially remove some of the overhead of looking for the annotations
)
...
- Should emit the minimum byte code required for emitting the event
- Should generate the minimum amount of support classes and code required for emitting the event
Links
Overview
Content Tools