JDK-6590257 : ssv.dll base address may conflict with other JRE DLLs
- Type: Bug
- Component: deploy
- Sub-Component: deployment_toolkit
- Affected Version: 6u2
- Priority: P3
- Status: Closed
- Resolution: Fixed
- OS: windows
- CPU: generic
- Submitted: 2007-08-07
- Updated: 2010-09-17
- Resolved: 2008-06-19
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
| JDK 6 | JDK 7 |
|---|---|
6u10 b07Fixed  |
7Fixed |
Related Reports
|
Relates :
|
|
|
Relates :
|
Description
The Deploy workspace build has a "rebase-dlls" target that rebases everything in $outputdir/bin/*.dll, including ssv.dll. Now the Install workspace also has a "rebase" target. The Install workspace appears to rebase everything in j2re-image/*.dll, *except* ssv.dll. This can be seen in the build log file. Based on this, it is possible (with some bad luck) to get another dll conflicting with ssv.dll.
It appears this is what happened in 1.6.0_02, with jvm.dll and ssv.dll:
C:\Program Files\Java\jre1.6.0_02\bin> dumpbin /headers ssv.dll | grep 'image base'
6D7C0000 image base (6D7C0000 to 6D838FFF)
C:\Program Files\Java\jre1.6.0_02\bin> dumpbin /headers client\jvm.dll | grep 'image base'
6D7C0000 image base (6D7C0000 to 6DA08FFF)
So in 6u2, jvm.dll will get relocated if it's loaded in a browser process where ssv.dll is already present. Loading up a browser process under windbg and using the "!imgreloc" command confirms this. Image relocation can potentially affect startup time and to a lesser extent, maximum size of the Java heap.
We should probably do the rebase in one place only.
Comments
|