Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mark stop() method as noinline #1485

Merged
merged 2 commits into from
Sep 25, 2024
Merged

mark stop() method as noinline #1485

merged 2 commits into from
Sep 25, 2024

Conversation

pjfanning
Copy link
Contributor

@pjfanning pjfanning commented Sep 17, 2024

relates to #1484

I have similar issues in https://github.com/pjfanning/micrometer-pekko and this change fixes the broken test I ran into there when upgrading to Pekko 1.1.

I have tested this locally and it fixes the issue in micrometer-pekko.

More changes will be needed for Kamon but I'm raising this to show a path forward and to see if this acceptable for Pekko 1.1.2. We can add more changes in more PRs.

I won't merge this until a few people have reviewed it and there are no objections.

fyi @hughsimpson

@@ -159,7 +159,7 @@ private[pekko] trait Dispatch { this: ActorCell =>
catch handleException

// ➡➡➡ NEVER SEND THE SAME SYSTEM MESSAGE OBJECT TO TWO ACTORS ⬅⬅⬅
final def stop(): Unit =
@noinline final def stop(): Unit =
Copy link
Member

Choose a reason for hiding this comment

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

I wonder why this method has been inline. Does us toggle something on? If does, for those method like start, resume, suspend shouldn't be inline too.

Copy link
Contributor

@jrudolph jrudolph Sep 18, 2024

Choose a reason for hiding this comment

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

The Scala compiler is free to inline methods when it is sound. This is the case, when the final receiver of a call can be determined. Whether or not that has any performance impact is always hard to say. In general, the JVM JIT compilation will also do heavy inlining and may in many cases do the same kind of optimizations at runtime. In other cases, like e.g. for higher-order methods, the Scala compiler might be able to generate significantly less code by earlier inlining, which also helps JIT compilations.

That said, the point of adding @noinline here is that some telemetry tools like Kamon instrument internal APIs to do their work. This has mainly historic reasons. In the future, it could be better to introduce official hooks for these kinds of use cases, so that it is easier to track what the public telemetry API is instead of relying on keeping some internal APIs stable.

Copy link
Member

Choose a reason for hiding this comment

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

Thanks for the clarification. @jrudolph

Copy link
Member

Choose a reason for hiding this comment

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

I am not sure this PR can be resolve the kamon issue, because Kamon Instruementation seem like didn't advise/intercept this method.

the stack trace of the original issue post shows that the DispatcherPrerequisites weren't assigned correctly.

Is it probably caused by this inline?

@inline def fromFunction[A, B](f: A => B): scala.PartialFunction[A, B] =
scala.PartialFunction.fromFunction(f)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks @Roiocam - there will need to be more changes. This PR is just to show one change and to highlight that the change doesn't break anything (tests or binary compatibility checks).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

#1489 adds more annotations

@jrudolph
Copy link
Contributor

jrudolph commented Sep 18, 2024

It would be good to document these unwritten compatibility constraints. In Akka, we used @InternalStableApi but any kind of simple documentation will help to later understand the reasoning behind adding something like @noinline (which otherwise is very uncommon in Scala and has potential performance impacts in the future).

@pjfanning pjfanning marked this pull request as ready for review September 20, 2024 10:44
@pjfanning
Copy link
Contributor Author

It would be good to document these unwritten compatibility constraints. In Akka, we used @InternalStableApi but any kind of simple documentation will help to later understand the reasoning behind adding something like @noinline (which otherwise is very uncommon in Scala and has potential performance impacts in the future).

@jrudolph I've summarised the situation in intro to #1487 and the aim of that discussion is to discuss how we can remove the @noinline annotations at some point in the future.

@pjfanning
Copy link
Contributor Author

#1489 was merged - would it be possible for any Pekko PMC members to review this? This change is more useful for micrometer-pekko than Kamon.

Copy link
Contributor

@nvollmar nvollmar left a comment

Choose a reason for hiding this comment

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

lgtm

@pjfanning pjfanning merged commit f24e436 into apache:main Sep 25, 2024
9 checks passed
@pjfanning pjfanning deleted the noiline branch September 25, 2024 09:00
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