Bug 513605 - Updating/Installing OpenJDK should recreate the shared class-data archive
Summary: Updating/Installing OpenJDK should recreate the shared class-data archive
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: java-1.6.0-openjdk
Version: rawhide
Hardware: i686
OS: Linux
low
medium
Target Milestone: ---
Assignee: jiri vanek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 878181 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-07-24 13:09 UTC by Clemens Eisserer
Modified: 2013-02-22 18:46 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-22 07:35:04 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Clemens Eisserer 2009-07-24 13:09:00 UTC
Description of problem:

After updating OpenJDK, class-data-sharing (cds) always is broken.
Class-Data sharing is a technique for sharing basic system classes between mutiple running jvm's to reduce memory consumption and faster startup.

The shared archive can be created using the following command, this has to be executed every time OpenJDK is updated:
> java -Xshare:dump

To check wether class-data-sharing is operational:
> java -client -Xshare:on -jar ....


Version-Release number of selected component (if applicable):
java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.5) (fedora-24.b16.fc12-i386)
OpenJDK Server VM (build 14.0-b15, mixed mode)


Steps to Reproduce:
1. Install OpenJDK
2. Generate the shared archive as root: java -Xshare:dump
3. Update OpenJDK
4. Start your favourite java app with cds turned on java -client -Xshare:on -jar
  
Actual results:
Every update breaks CDS.

Expected results:
Ideally the shared archive should be created when installing OpenJDK, and automatically re-created every time when updating it.
Java will automatically use the archive.

Comment 1 Bug Zapper 2009-11-16 11:05:57 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 3 Clemens Eisserer 2010-05-27 06:39:33 UTC
F13 has been released and its still not fixed :/

Comment 4 Mark Wielaard 2010-05-27 08:16:08 UTC
Can this be done upstream as part of the build process? If IcedTea had a -Xshare:dump step in the Makefile as last step to force the CDS in the image to be installed, would that work? Then all distros would benefit from this.

Comment 5 Andrew John Hughes 2010-09-06 12:21:11 UTC
Possibly.  It is arch-specific:

http://download.oracle.com/javase/1.5.0/docs/guide/vm/class-data-sharing.html

On x86_64, I just get:

$ java -Xshare:dump
Error occurred during initialization of VM
Dumping a shared archive is not supported on the Server JVM.

Comment 6 Bug Zapper 2010-11-04 10:42:00 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 7 Clemens Eisserer 2010-11-04 11:16:33 UTC
please keep it open, the issue still exists.

Comment 8 Andrew John Hughes 2012-11-20 01:47:15 UTC
*** Bug 878181 has been marked as a duplicate of this bug. ***

Comment 9 Andrew John Hughes 2012-11-20 16:15:24 UTC
Fixed in IcedTea6:

http://icedtea.classpath.org/hg/icedtea6/rev/dfe3209fcf64

This will be in the 1.12 release and then in the corresponding Fedora package for 1.6 when released.

For 1.7, matching changes will need to be made to the RPM spec file by the package maintainer.

Comment 10 Lukas Zapletal 2012-11-20 17:35:55 UTC
Thanks Andrew. In my Bug 878181 I have also reported that default behavior (-Xdump:auto) does not seem to be working. At least I get the very same startup times as for -Xdump:off. Could you check if this is working? It's great we have it!

Comment 11 Andrew John Hughes 2013-01-21 15:18:33 UTC
1.12 hasn't been released yet.  Once it is and rolls into Fedora (I expect in the next month), you'll hopefully see the behaviour change.  Look for the file classes.jsa appearing in the JDK tree.

$ ls ~/build/icedtea6/jre/lib/amd64/server/
classes.jsa  libjsig.so@  libjvm.so*  Xusage.txt

(The directory will be different on other architectures like x86)

Comment 12 Andrew John Hughes 2013-01-29 22:01:27 UTC
1.12.0 is now available: http://blog.fuseyism.com/index.php/2013/01/29/icedtea6-1-12-released/

Comment 13 jiri vanek 2013-02-22 07:35:04 UTC
Dump added to post in spec files, should be ok now.

Comment 14 Clemens Eisserer 2013-02-22 18:46:12 UTC
Just updated Fedora-17, and I can confirm the shared class archive is generated and used.

Thanks!


Note You need to log in before you can comment on or make changes to this bug.