Skip to content

Fix inner classes matching for line probes#4604

Merged
jpbempel merged 3 commits into
masterfrom
jpbempel/fix-kotlin-lambda
Jan 30, 2023
Merged

Fix inner classes matching for line probes#4604
jpbempel merged 3 commits into
masterfrom
jpbempel/fix-kotlin-lambda

Conversation

@jpbempel

@jpbempel jpbempel commented Jan 26, 2023

Copy link
Copy Markdown
Member

What Does This Do

Allows the DebuggerTransformer to find inner classes when using file+line probe definitions.
Reporting of line not found was removed because it can be found latter by loading inner/top-level class.

Background

When class are already loaded, we need to retransform them for passing through the DebuggerTransformer.
But to detect which class need to be retransformed, we rely on the naming. However inner classes or Top-Level classes are independent class files and the only way to associate them is the sourcefile attribute in each class file.

Solution

Track all dependent classes by their source file, so it easier to find all related class given a filename.
This avoids scanning all loaded classes to parse their sourcefile and try to match with actual probe definitions.

Motivation

Support line probe in inner/top-level classes or Kotlin lambdas

Additional Notes

When class are already loaded, we need to retransform them for passing
through the DebuggerTransformer.
But to detect which class need to be retransformed, we rely on the
naming. However inner classes or Top-Level classes are in independent
class files and the only way to associate them is the sourcefile
attribute in each class file.
So we need to track all dependent classes by their source file in
order to avoid scanning all loaded classes to parse their sourcefile
and try to match with actual probe definitions.
@jpbempel
jpbempel requested a review from a team as a code owner January 26, 2023 11:18
@jpbempel
jpbempel requested review from shatzi and removed request for a team January 26, 2023 11:18

@shatzi shatzi left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Awesome stuff. few refactor suggestions

sourceFile = sourceFile.substring(idx + 1);
}
List<String> additionalClasses =
SourceFileTrackingTransformer.INSTANCE.getClassNameBySourceFile(sourceFile);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I don't like that use static INSTANCE and creating hidden dependencies that complicate how we do unit testing.
Lets clean this up to make more single responsibility classes

My take on this would be:

  1. Extract all getLoadedClasses logic from this class. maybe ClassesToRetansformFinder that gets list of changes, loaded classes and classFileMapping provider to do all this logic.
    a. that would make the configurationComparer simpler
    b. remote the dependency of SourceFileTrackingTransformer
  2. ClassesToRetansformFinder can have a function "registerClassWithCustomSourceName(classname, sourceilfe)
    a. then SourceFileTrackingTransformer can be created debuggerAgent an pass the instance of ClassesToRetansformFinder to it to register classes
    b. configuration updater can use ClassesToRetansformFinder.getAllChangedClasses(changes)

WDYT?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

sounds nice!
done

}
}

private String removeExtension(String fileName) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Maybe move all those helper functions to ClassFileHelper utility classes - to have a single place when we load file name, normalize it, etc.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

done

private static boolean lookupClass(Trie changedClasses, Class<?> clazz) {
String reversedTypeName = reverseStr(clazz.getName());
// try first with FQN (java.lang.String)
if (changedClasses.contains(reversedTypeName)) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

why not doing containsPrefix? as it the same we do at the end.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

done

if (sourceFile == null) {
return null;
}
String simpleClassName = className.substring(className.lastIndexOf('/') + 1);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

look like the normalize or removeExtention functions?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

done

@jpbempel
jpbempel force-pushed the jpbempel/fix-kotlin-lambda branch from ab594c2 to f85142e Compare January 27, 2023 14:49
handle the resolution of classes that need to be retransformed based
on SourceFile and probe definitions
@jpbempel
jpbempel force-pushed the jpbempel/fix-kotlin-lambda branch from f85142e to 01ee5e0 Compare January 27, 2023 14:53
@jpbempel jpbempel added the comp: debugger Dynamic Instrumentation label Jan 27, 2023
@jpbempel
jpbempel merged commit 8354652 into master Jan 30, 2023
@jpbempel
jpbempel deleted the jpbempel/fix-kotlin-lambda branch January 30, 2023 08:42
@github-actions github-actions Bot added this to the 1.7.0 milestone Jan 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp: debugger Dynamic Instrumentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants