Speeding up Truffle debugging

[jtulach]

• while working on Using Arrow Date32 format to transfer LocalDate across JVMs enso-org/enso#14632 I had to debug a lot
• it takes 40s to reach breakpoint
• Commenting out this line speeds Truffle debugger 10 times: 9e24c44

• of course, commenting out this line is not an option
• my goal in this PR is to speed the initialization while making the rest of the Truffle debugging functional

[mbien]

wondering if there is a relation to #7663

[jtulach]

• it seems that the exit method breakpoints prevent OpenJDK from optimizing properly
• maybe installing such a breakpoint forces running in interpreter mode?
• avoiding the exit method breakpoint or installing it for as little as possible shall improve the poor 40s delay

• of course, commenting out this line is not an option
• my goal in this PR is to speed the initialization while making the rest of the Truffle debugging functional

• with 6268481 I managed to get the time down to 10s
• that is still more than 4s without installing the exit method breakpoint on Engine.build()
• but it is better than previous 40s

wondering if there is a relation to #7663

• probably yes.
• If applying 9e24c44 speeds your case up, then yes,
• it is probably the exit method breakpoint cause

[mbien]

wondering if there is a relation to #7663

• probably yes.

• If applying 9e24c44 speeds your case up, then yes,

• it is probably the exit method breakpoint cause

commenting the addBreakpoint() call out appears to resolve the performance problem. But please note that the current version of this PR has it commented in and the problem does occur. (I didn't test anything else, e.g if the breakpoints still work)

also please note that none of the debugger tests ran so far, i added the labels which will enable them on next sync.

would be also curious to find out why the debugger has to call into polyglot/GraalEngine code when the maven new-project wizard runs

[neilcsmith-net]

would be also curious to find out why the debugger has to call into polyglot/GraalEngine code when the maven new-project wizard runs

It's not specific to Maven. Same happens with other project types (eg. Ant and PHP). I'd initially thought something was triggered during cluster activation, but it's later during the new project creation. Seems to happen on first use of new project on subsequent runs too?

[mbien]

Same happens with other project types (eg. Ant and PHP).

interesting, didn't know that. I thought i tested the ant wizard as baseline and it worked fine, but it was a while ago by now.

I'd initially thought something was triggered during cluster activation, but it's later during the new project creation. Seems to happen on first use of new project on subsequent runs too?

at least in case of maven, second run within the same session is faster since there is quite some maven initialization going on during first run. #7590, however usually this is <2s and it happens before you can click next. First run performance while debugging is completely upredictable, the slowest run was 7mins, some were 40s. The issue has more info, bencharmks and flame graphs.

[jtulach]

• the big question to ask:
• can we rely on com.oracle.truffle.polyglot.PolyglotImpl.buildEngine being there in subsequent releases of Truffle API?
• Engine.Builder.build() was an official API - it is not going to go away
• PolyglotImpl.buildEngine(...) is just an implementation
• but the speedup improvement is tempting

[entlicher]

This might be an option, even though it's prone to break when the impl changes. I don't expect Truffle to change much these days, it's much more mature than it was during the engines and instrumentation development, which broke our Truffle debugger in the past. Even though we never know what happens to the private stuff.

I'll test the class loading order - maybe we could test if PolyglotImpl.buildEngine() is there and if yes then use it, if not then fall back to the public method.