Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update handlers in jfr-streaming to match spec #616

Merged
merged 6 commits into from
Nov 29, 2022

Conversation

roberttoyonaga
Copy link
Contributor

Description:
These changes try to update the existing JFR streaming handlers to match the specification here. I think this is needed because it seems as though the handler implementations and the spec have fallen a bit out of sync.

Testing:

Tests were adjusted accordingly to match the updated handler implementations.

Outstanding items and questions:

Tests for specific GC implementations (G1, parallel) have been omitted. I am not sure of a good way to guarantee a specific implementation is used for specific tests.

None of the metrics process.runtime.jvm.memory.* will include theAttribute pair (type,"nonheap"). Question: Doesn't non-heap memory fall under the process.runtime.jvm.buffer.* metrics?

Not all of the pool names of the metrics process.runtime.jvm.memory.* are covered yet. This is in part because we require JDK JFR support to actually emit data for missing pools in JFR events, and partly because more handlers for other GC implementations need to be written in the future.

Copy link
Contributor

@breedx-splk breedx-splk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for getting these updates in place, much appreciated! Just had a few ideas but looks good overall.

if (youngSpaceObj instanceof RecordedObject) {
RecordedObject youngSpace = (RecordedObject) youngSpaceObj;
if (youngSpace.hasField(COMMITTED_SIZE)) {
committedYoung = youngSpace.getLong(COMMITTED_SIZE);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This pattern of checking a field, getting that field, then casting it to RecordedObject is repeated several times here. What if you had a helper method like this:

  private void doIfAvailable(RecordedEvent event, String field, Consumer<RecordedObject> closure){
    if(!event.hasField(field)) {
      return;
    }
    Object value = event.getValue(field);
    if(value instanceof RecordedObject){
      closure.accept((RecordedObject) value);
    }
  }

then you can just invoke a few times like:

doIfAvailable(event, "edenSpace", edenSpace -> {
  if (edenSpace.hasField(USED)) {
    if (before) {
      usageEden = edenSpace.getLong(USED);
    } else {
      usageEdenAfter = edenSpace.getLong(USED);
    }
  }
});
...

I think that would help with some of the boilerplate there without building up too much "infrastructure".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good idea! I implemented your suggestion

roberttoyonaga and others added 4 commits November 29, 2022 10:03
…cs/internal/memory/G1HeapSummaryHandler.java

Co-authored-by: jason plumb <75337021+breedx-splk@users.noreply.github.com>
…cs/internal/memory/GCHeapSummaryHandler.java

Co-authored-by: jason plumb <75337021+breedx-splk@users.noreply.github.com>
…cs/internal/memory/ParallelHeapSummaryHandler.java

Co-authored-by: jason plumb <75337021+breedx-splk@users.noreply.github.com>
@roberttoyonaga roberttoyonaga requested review from breedx-splk and removed request for kittylyst and jack-berg November 29, 2022 16:17
Copy link
Contributor

@breedx-splk breedx-splk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks again!

@trask
Copy link
Member

trask commented Nov 29, 2022

thx!

@trask trask merged commit 4cc38b8 into open-telemetry:main Nov 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants