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.