Skip to content

Draft: Add new loop detector #921

Draft
acturcu wants to merge 56 commits intoJetBrains:developfrom
acturcu:new-loop-detector
Draft

Draft: Add new loop detector #921
acturcu wants to merge 56 commits intoJetBrains:developfrom
acturcu:new-loop-detector

Conversation

@acturcu
Copy link

@acturcu acturcu commented Jan 14, 2026

@eupp

This PR contains the basic LoopDetector API. A small description:

For the moment, I've made the LoopDetector maintain a per thread state image with the next ideas:

  • Each thread has a queue of Methods Called
  • Each Method Called has an id, a depth and a stack of active loops
  • Each Active Loop has id, iteration count and whether they have been switched or are marked stuck. Counters for Switch and Stuck are individual.

For a thread when first entering a loop, we either create a dummy frame or use the one we are in and push a new ActiveLoop onto it. During the other iterations of the loop, the methodIds are verified to match, the counter is increased and the thresholds are verified. When finishing a loop it removes the ActiveLoop from the stack.

On method level, we verify the top method on the stack, and if it matches with the current methodId it means we encounter some recursion, so the depth counter is incremented. If the depth > threshold then for the time being we declare the loop as stuck and try to switch the thread. On method exit we either decrease the depth or we remove the method from the stack (depth is 0)

@acturcu acturcu changed the title Add new loop detector Draft: Add new loop detector Jan 14, 2026
@acturcu acturcu closed this Jan 19, 2026
@acturcu acturcu reopened this Jan 19, 2026
…StartTracePoint is not added to the trace, but LoopEndTracePoint is, so the iterations are not grouped together
methodName = "run",
methodType = Types.MethodType(Types.VOID_TYPE)
)
popMethodId(currentThreadId, methodId)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's instead add methods to loop detector:

fun beforeThreadRun(...)
fun afterThreadRun(...)

@eupp eupp mentioned this pull request Feb 10, 2026
acturcu and others added 25 commits February 12, 2026 00:55
* Fix a subtle bug involving checks for package names that were shadowed and re-located. The shadow jar plugin substitutes all string literals in the source code that contain names of relocated packages. So special care is required when performing checks against names of relocated packages.

* Thanks to @dmitrii-artuhov for a clever hack on how to circumvent package shadowing in strings.

Signed-off-by: Evgeniy Moiseenko <evg.moiseenko94@gmail.com>
Signed-off-by: Evgeniy Moiseenko <evg.moiseenko94@gmail.com>
Signed-off-by: Evgeniy Moiseenko <evg.moiseenko94@gmail.com>
…tBrains#942)

Signed-off-by: Evgeniy Moiseenko <evg.moiseenko94@gmail.com>
---------

Signed-off-by: Evgeniy Moiseenko <evg.moiseenko94@gmail.com>
---------

Signed-off-by: Evgeniy Moiseenko <evg.moiseenko94@gmail.com>
…ains#948)

---------

Signed-off-by: Evgeniy Moiseenko <evg.moiseenko94@gmail.com>
Co-authored-by: Evgeniy Moiseenko <evg.moiseenko94@gmail.com>
Signed-off-by: Evgeniy Moiseenko <evg.moiseenko94@gmail.com>
---------

Signed-off-by: Evgeniy Moiseenko <evg.moiseenko94@gmail.com>
Re-creation of two hash sets on each call can be accounted for generation 50% of memory allocations in reading trace.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants