A noob question about weird sequence of `*synchronization entry` in a C2 compiled code

[Jaroslav Bachorík]

Hi Dean,

Thanks for taking a look at this! The recursion does not sound very
plausible, though.
The code is doing something like this

```
227 for (IItem event : eventIterable) {
228   long value = valueAccessor.applyAsLong(event);
229   if (value == 0) {
230     continue;
231   }
232   IMCStackTrace jmcStacktrace = stacktraceAccessor.getMember(event);
233   if (jmcStacktrace == null) {
234     continue;
235   }
  ....
```

Unfortunately, I can not share the full code :( But there is
definitely no recursion happening at L227.

What I find confusing here, is that even if the '*synchronization
entry' items are demarking 'before BCI' for the inlined methods they
get mixed up with the 'before BCI' code of the inilining method,
making it quite impossible to attribute the CPU samples properly - eg.
all 'before BCI' code of all inlined methods would be attached to the
first line of the inilining method in JFR stacktraces messing up the
resulting profile by overemphasizing the costs of the iniling method.

Is this the hard limitation of what is possible to do with the debug
data at this level of optimization? Are some boundaries irreversibly
lost here?

Cheers,

-JB-

On Sat, Feb 5, 2022 at 10:49 AM <dean.long at oracle.com> wrote:
>
> Hi Jaroslav.  It looks like the code is mostly calling and returning.
> It looks like a recursive method that is getting inlined.  The
> "synchronization entry" seems to happen at method entry or exit (where
> the bci is set to -1).
>
> dl