I wonder if we really need to be explicit here. Do we really care what package the compiled method is coming from?

are you suggesting checking against \\w+/.*to match any packages that might be external?

In this case I don't really see the need as the test is plain JDK test which should always start from the above packages (sun,java,jdk)

are you suggesting checking against \w+/.*to match any packages that might be external?

Yes. But I'm not saying we should target external packages, just that perhaps we don't care about the package we catch here.

I think we should care about the base package name as that acts as a simple sanity test that async-profiler is adding logical frames to the generated stacks

Fair enough

Thanks, but my question is different. How come that none of basic java/lang classes (String, Thread, Class, etc.) were seen in the compilation profile? Weren't these methods compiled, or they were but async-profiler did not catch any? How can I reproduce the issue? (Haven't seen it so far)

I'm attaching some flame graphs, when checked both show that both C1 & C2 compiler are working fine & are being sampled as we expect them to,

It's just that C1 compiler is simply fast & sometimes is not sampled for the classes/methods directly under java/lang package
=> Reducing the sampling interval increases the stability of the test.

If we check the available samples for C1 we can see the synthetic frames & we can see that each method was sampled only once which is what we expect to see

Due to the high performance of C1 it was possible for certain runs to not capture samples for the methods we currently expect, as such changing the pattern was needed,

I didn't see a value in picking one package over another as we may fall into the same issue in the future, so I opted for a pattern that should match any java synthetic frame

The java/lang can be still be seen on C2 compiler, and each method is only sampled once which is what we expect to see.
However to keep the check uniform, I opted to change the pattern for C2 as well.

flamegraph.html
flamegraph2.html

Thanks, that makes sense.
The pattern, however, does not make difference between a class name and a method name. I'd like the test verify that it's a Java method that is inserted as a synthetic frame, i.e. frame name contains one dot.

Sure, that make sense, I will update the pattern

Pattern update to better match java methods

New pattern (java|sun|jdk)/[^;]+[^;/]\.[^;/]+

• (java|sun|jdk) => top package sanity check
• /[^;]+ => checks for nested packages
• [^;/].[^;/]+ => checks a method name that shouldn't contain "/;" characters & should have a "." in it