Bug 498109

Summary: Enable static marker support for systemtap
Product: [Fedora] Fedora Reporter: Mark Wielaard <mjw>
Component: java-1.6.0-openjdkAssignee: Lillian Angel <langel>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: dbhole, langel, lkundrak, mark
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 1.6.0.0-18.b16.fc10 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-05-29 10:09:47 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 546295    
Attachments:
Description Flags
spec file patch to update to icedtea 1.5pre plus systemtap support none

Description Mark Wielaard 2009-04-28 17:22:07 EDT
Please consider adding static marker support for Systemtap. This is part of the
Fedora Systemtap Static Probes effort:
https://fedoraproject.org/wiki/Features/SystemtapStaticProbes

Some examples of what is possible when enabling this can be seen in this email: http://article.gmane.org/gmane.comp.java.openjdk.distro-packaging.devel/5444

The support and associated hotspot.stp tapset is enabled and installed when configuring with --enable-systemtap (this requires a dependency on the systemtap-sdt-devel package) and setting --with-abs-install-dir=usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0
Comment 1 Lillian Angel 2009-04-28 17:59:10 EDT
I approve the patch, go ahead and apply this. Close the bug when you have.

One thing- please add to the README/INSTALL file the build requirements and a blurb. Also, update the icedtea wiki with the systemtap requirement.

One question about the installation directory. If you install it under openjdk/build/linux-{arch}, it will get copied to j2sdk-image anyways. Would that suffice? Do you not want/need this in j2re-image?


Thanks a lot for this.
Comment 2 Mark Wielaard 2009-04-29 10:58:13 EDT
(In reply to comment #1)
> I approve the patch, go ahead and apply this. Close the bug when you have.

Do you want me to update the rpm spec file with the right configure flags and an updated source bundle? I thought it might be better to wait till upstream creates a new release with everything already in it. But I can extract the needed patches and add them to the rpm if you want.

> One thing- please add to the README/INSTALL file the build requirements and a
> blurb. Also, update the icedtea wiki with the systemtap requirement.

Upstream now has updated instructions and documentation on this feature in various places.

> One question about the installation directory. If you install it under
> openjdk/build/linux-{arch}, it will get copied to j2sdk-image anyways. Would
> that suffice? Do you not want/need this in j2re-image?

The markers are always build into the libjvm.so, and it doesn't matter where that is installed. The (helper/convenience - you can actually use the raw markers with stap, but the tapset is nicer) tapset/hotspot.stp should IMHO only be installed in the sdk/-devel package since it is more for developers (although administrators and end users might also be interested in tracing their apps).

The important thing is that the probes in the hostspot.stp point to the (absolute) path of the client/server libjvm.so libraries used at runtime.
Comment 3 Lillian Angel 2009-04-29 11:59:13 EDT
(In reply to comment #2)
> (In reply to comment #1)
> > I approve the patch, go ahead and apply this. Close the bug when you have.
> 
> Do you want me to update the rpm spec file with the right configure flags and
> an updated source bundle? I thought it might be better to wait till upstream
> creates a new release with everything already in it. But I can extract the
> needed patches and add them to the rpm if you want.

nope, we can wait. let's wait until upstream does it.

> 
> > One thing- please add to the README/INSTALL file the build requirements and a
> > blurb. Also, update the icedtea wiki with the systemtap requirement.
> 
> Upstream now has updated instructions and documentation on this feature in
> various places.

thanks

> 
> > One question about the installation directory. If you install it under
> > openjdk/build/linux-{arch}, it will get copied to j2sdk-image anyways. Would
> > that suffice? Do you not want/need this in j2re-image?
> 
> The markers are always build into the libjvm.so, and it doesn't matter where
> that is installed. The (helper/convenience - you can actually use the raw
> markers with stap, but the tapset is nicer) tapset/hotspot.stp should IMHO only
> be installed in the sdk/-devel package since it is more for developers
> (although administrators and end users might also be interested in tracing
> their apps).
> 
> The important thing is that the probes in the hostspot.stp point to the
> (absolute) path of the client/server libjvm.so libraries used at runtime.  


sounds good.


let me know how the spec file should be updated before release time.
Comment 4 Mark Wielaard 2009-05-10 15:24:26 EDT
Created attachment 343290 [details]
spec file patch to update to icedtea 1.5pre plus systemtap support

The attached spec.patch updates the package to IcedTea 1.5pre (current mercurial checkout) and adds systemtap support by configuring --enable-systemtap, setting --with-abs-install-dir, updating the build requirements and installing the tapset files and adding links to them in the systemtap tapset directory.

There are a couple of TODO items:
- I didn't know how to properly update the src zips for openjdk and hotspot, so I used the upstream defaults myself. When those are updated, then the --with-*-src-zip configure options need to put back.
- There are a couple of patches that are now in upstream, or conflict with it. I removed them all, but it would be good to double check they have all been actually merged into upstream sources.

The test results look OK, if you ignore a couple of failures with AWT/X not getting initialized properly. I don't know why the package build seems to have trouble connection to the fake X server sometimes. When running the tests by hand on a machine with DISPLAY setup normally these AWT/X connection failures don't happen.

--------------- jtreg console summary for hotspot ---------------
Test results: passed: 21
--------------- jtreg console summary for langtools ---------------
Test results: passed: 1,352
--------------- jtreg console summary for jdk ---------------
Test results: passed: 3,223; failed: 140; error: 1

That last result changed to the following when run by hand:
Test results: passed: 3,328; failed: 17; error: 2

The resulting 17 failures did look like they are "expected" (as in, upstream bugs/failures also).

Mauve had 7 of 2568 tests failed. The 7 test failures were all related to not properly starting AWT/X.

Unfortunately the systemtap support doesn't work out of the box with systemtap 0.9.7, but this is a bug in the systemtap runtime. I have already pushed a fix upstream http://sourceware.org/bugzilla/show_bug.cgi?id=10139 when a release with that fix, or that fix is backported, the systemtap support will automagically start working. So I would like to see the package build with systemtap support now already if possible.
Comment 5 Fedora Update System 2009-05-30 10:16:18 EDT
java-1.6.0-openjdk-1.6.0.0-18.b16.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/java-1.6.0-openjdk-1.6.0.0-18.b16.fc10
Comment 6 Fedora Update System 2009-05-30 10:17:13 EDT
java-1.6.0-openjdk-1.6.0.0-22.b16.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/java-1.6.0-openjdk-1.6.0.0-22.b16.fc11
Comment 7 Fedora Update System 2009-06-02 10:23:02 EDT
java-1.6.0-openjdk-1.6.0.0-22.b16.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 8 Fedora Update System 2009-06-02 10:30:36 EDT
java-1.6.0-openjdk-1.6.0.0-18.b16.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.