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

Ensure to check the runtime log level for RequestContext tracing needs #27736

Merged
merged 1 commit into from Sep 6, 2022
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
Expand Up @@ -39,15 +39,11 @@ class RequestContext implements ManagedContext {
private final LazyValue<Notifier<Object>> beforeDestroyedNotifier;
private final LazyValue<Notifier<Object>> destroyedNotifier;

private final boolean traceEnabled;

public RequestContext(CurrentContext<RequestContextState> currentContext) {
this.currentContext = currentContext;
this.initializedNotifier = new LazyValue<>(RequestContext::createInitializedNotifier);
this.beforeDestroyedNotifier = new LazyValue<>(RequestContext::createBeforeDestroyedNotifier);
this.destroyedNotifier = new LazyValue<>(RequestContext::createDestroyedNotifier);
// we do not need to check the effective log level
this.traceEnabled = LOG.isTraceEnabled();
}

@Override
Expand Down Expand Up @@ -126,7 +122,7 @@ public void destroy(Contextual<?> contextual) {

@Override
public void activate(ContextState initialState) {
if (traceEnabled) {
if (LOG.isTraceEnabled()) {
String stack = Arrays.stream(Thread.currentThread().getStackTrace())
Copy link
Contributor

@franz1981 franz1981 Sep 5, 2022

Choose a reason for hiding this comment

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

Unrelated but useful: always move away "unlikely" paths ie cold ones out of the "main" method logic: it would increase chances to inline it (see http://normanmaurer.me/blog_in_progress/2013/11/07/Inline-all-the-Things/ that's still very actual and these things hasn't changed across JDK versions, really).
Most inlining decisions on OpenJDK happens based on the bytecode size (although not always; sometime the native method size is important too), meaning that using any bytecode plugin viewer (I use https://plugins.jetbrains.com/plugin/9248-jclasslib-bytecode-viewer) can help checking how much the bytecode size change while grouping differently code into methods:
eg

if (LOG.isTraceEnabled()) {
    traceActivate(...);
}

this is going to reduce a bit the bytecode size of the original method, increasing its chance to be inlined in the common use case

Copy link
Member Author

Choose a reason for hiding this comment

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

Very true, but in this case I preferred the simplest patch to expedite integration & minimize friction for backports.

Definitely something to consider if someone wants to get back to this and improve further.

Copy link
Contributor

Choose a reason for hiding this comment

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

Agree!

.skip(2)
.limit(7)
Expand Down Expand Up @@ -164,7 +160,7 @@ public ContextState getStateIfActive() {

@Override
public void deactivate() {
if (traceEnabled) {
if (LOG.isTraceEnabled()) {
String stack = Arrays.stream(Thread.currentThread().getStackTrace())
.skip(2)
.limit(7)
Expand All @@ -182,7 +178,7 @@ public void destroy() {

@Override
public void destroy(ContextState state) {
if (traceEnabled) {
if (LOG.isTraceEnabled()) {
String stack = Arrays.stream(Thread.currentThread().getStackTrace())
.skip(2)
.limit(7)
Expand Down