-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Change CSV format of call tree report #8774
Conversation
Thank you for your pull request and welcome to our community! To contribute, please sign the Oracle Contributor Agreement (OCA).
To sign the OCA, please create an Oracle account and sign the OCA in Oracle's Contributor Agreement Application. When signing the OCA, please provide your GitHub username. After signing the OCA and getting an OCA approval from Oracle, this PR will be automatically updated. If you are an Oracle employee, please make sure that you are a member of the main Oracle GitHub organization, and your membership in this organization is public. |
Thank you for signing the OCA. |
@galderz Are you okay with merging this PR or would you like some changes? |
@d-kozak Looks good |
And thanks @mv02 for tackling this! |
Related issue: #8496
This pull request reworks and simplifies the CSV output format of call graph report, generated by running Native Image with the
-H:+PrintAnalysisCallTree
and-H:PrintAnalysisCallTreeType=CSV
options.The new format consists of 3 files:
call_tree_methods.csv
call_tree_invokes.csv
call_tree_targets.csv
The first two files represent a list of methods and invokes, respectively, while the targets file creates a many-to-many mapping between invokes and target methods. This replaces the original system of direct and virtual nodes and edges. Direct and virtual calls are simply distinguished by
IsDirect
and they are connected to all relevant method implementations. Entrypoints are not listed in a separate file anymore, instead they are marked by a new column in the methods file.Most importantly, the new format eliminates the imprecision described in #8496.