search

eclipse-openj9 / openj9

Eclipse OpenJ9: A Java Virtual Machine for OpenJDK that's optimized for small footprint, fast start-up, and high throughput. Builds on Eclipse OMR (https://github.com/eclipse/omr) and combines with the Extensions for OpenJDK for OpenJ9 repo.
Other
3.28k stars 721 forks source link

Traceformat should not erase tracepoint detail #8335

Open dusanboskovic opened 4 years ago

dusanboskovic commented 4 years ago

The Trc_BCU_internalDefineClass_FullData tracepoint should output data in a more human readable format, example below:

19:59:52.031602000  0x0000000002247e00 j9bcu(j9vm).198     Event       BCU Trc_BCU_internalDefineClass_FullData: data=????^@^@^@4^@^G^G^@^E^G^@^F^A^@
SourceFile^A^@^NCloneable.java^A^@^Sjava/lang/Cloneable^A^@^Pjava/lang/Object^F^A^@^A^@^B^@^@^@^@^@^@^@^A^@^C^@^@^@^B^@^D, classLoader=0x7fa47c07f8b8
DanHeidinga commented 4 years ago

I had to dig through a lot of internal history to find the purpose of that tracepoint.

The purpose is to capture the raw bytes from a class before it's defined using a command like:

java -Xtrace:none -Xtrace:maximal={j9bcu.198,j9bcu.1},output=c:\170\boo -version

It's defined at level 7 as it shouldn't be enabled by default. Unfortunately, trying to make it more readable would make it less useful for the above purpose.

What brought it to your attention?

DanHeidinga commented 4 years ago

My preference would be to remove this tracepoint in the future and replace it with a new -Xdump:classbytes option to allow capturing classes at the defineClass call

keithc-ca commented 4 years ago

What Dusan suggests would have no effect on the example above using output=....

People use the command traceformat c:\170\boo and then examine c:\170\boo.fmt. It's not helpful that a lot of information has been erased as c:\170\boo.fmt is produced. As I understand it, he's asking that there is a way to avoid that erasure.