RFR: 8311993: Test serviceability/sa/UniqueVtableTest.java failed: duplicate vtables detected [v3]

[Kevin Walls]

On Wed, 28 Aug 2024 23:30:33 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> On Windows SA agent gets a class vtable from symbols, exported from jvm.dll (it exports symbols like "??_7" + type + "@@6B@").
>> But symbol lookup function first requests WinDbg about the symbol.
>> Sometimes WinDbg routine IDebugSymbols::GetOffsetByName() returns offset for both class and class pointer types. Returned offsets correspond to symbols like "jvm!class_name::`vftable'".
>> The behavior is intermittent, I was not able to find what is the reason.
>> The fix adds workaround for the case - if GetOffsetByName succeeded, we check if corresponding symbol contains requested one.
>> So it returns expected offset for non-vtable symbols like "MaxJNILocalCapacity" (GetOffsetByName returns offset for "jvm!MaxJNILocalCapacity"), but returns 0 for vtlb lookup.
>> 
>> Additionally added check for results of IDebugSymbols::SetImagePath/SetSymbolPath
>> 
>> Testing: tier1,tier2,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed extra space

I thought it odd that we lookup symbols including the *, e.g.
Duplicate vtable: 0x00007ffd233633d8:
  - CompiledMethod (extends CodeBlob)
  - CompiledMethod* (extends null)

And iterating over  agent.getTypeDataBase().getTypes(); we see e.g. jbyte, jbyte*, jbyte** which looks odd and unnecessary.

We know what a pointer is, so not needing to lookup up "jbyte*" might be good also.
But that might be more change than we want to do right now, so this double check looks good.

-------------

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20684#pullrequestreview-2275335513