Support advanced stack walking features with cstack=vm #1537
Conversation
But wouldn't that keep the known issue of allocation profiling not collecting native samples for 
When using VM stack walker they won't have these native frames, You can test this change against the |
| } | ||
| continue; | ||
| } else { | ||
| if (features.vtable_target && nm->isVTableStub() && depth == 0) { |
There was a problem hiding this comment.
can we add a test for this?
There was a problem hiding this comment.
Added tests for vtable stub and itable stub
|
@Baraa-Hasheesh You are right: ideally, allocation profiling should use VMStructs stack walker too. But let's do it in a separate PR. |
That's should be fine |
2 participants
Description
This PR is a prerequisite to making
cstack=vmthe default stack walking mode.It includes the following changes:
vmandvmxare no longer different stack walking modes. It's now a singlevmmode with an optionalmixedfeature. There is already-Fargument for choosing various stack walking features, and the ability to display mixed stack (where native frames interleave Java frames) fits this paradigm well.cstack=vmxremains for backward compatibility as a shorthand forcstack=vm,features=mixed.StackDetailenum is gone. Now, I passfeaturesargument instead.vtableandcomptaskfeatures.nativememprofiles, I chop everything above malloc hook frames, similarly tofpanddwarfmodes.I haven't changed logic around allocation and lock profiling. They still use JVMTI API for getting stack traces. This will keep familiar user experience after switching to
vmby default.Related issues
#1533, #1370
Motivation and context
VMStructs should support all stack walking features that
fpanddwarfmodes do.How has this been tested?
--cstack vm -F comptask+vtableIntegration tests will be amended in the subsequent PR that changes default mode.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.