Hi,
I just downloaded the optimized VACPP 0.6 and got the following problem:
I have WSEB with Fixpack 2 on SMP with 2 Intel Celeron. (no kernel
fixes, just fixpack 2)
It starts loading, displays the "IBM Web Browser" logo and then hangs
the system. I can not even move the mouse or CAD.
Just to let you know...
Robert Henschel
Michael Kaply schrieb:
>
> I have uploaded a fully optimized VACPP Warpzilla 0.6 (aka IBM Web
> Browser) to mozilla.org:
>
>
>ftp://ftp.mozilla.org/pub/mozilla/releases/mozilla0.6/mozilla-i386-pcos2-vacpp-opt-0.6.zip
>
> Before you ask, the main reason we chose 0.6 is because we wanted a
> known stable entity to work with, and all of the concepts are the same.
> The code we wrote will go into the trunk and future milestones. We also
> chose it for the more obvious reason that IBM pays my bills :)
>
> This build reflects a lot of work that has been done by my team to
> improve the performance of the VACPP Warpzilla.
>
> Here is a quick summary:
>
> 1. We have rewritten xptcstubs and xptcinvoke in XPCOM. This was
> necessary to enable optimization in the compiler. There was code in
> these functions that did not work when the code was optimized. We also
> hand tuned these functions to make them faster. Thanks to Jeff Jones and
> Javier Pedemonte for these changes.
>
> 2. NSPR has some atom functions that were either inline assembly or C
> runtime calls on all platforms except OS/2. On OS/2, we were using the
> generic NSPR implementation which were VERY slow. We have implemented
> them in assembly.
>
> BIG NOTE - I did NOT include the RAM semaphores in this build. I want to
> determine whether or not the key performance issue was the
> PR_Lock/PR_Unlock code itself or the face that the atom code was calling
> it too much. If you want to try the new atom code AND the ramsems, use
> the NSPR4.ZIP which is at:
>
> ftp://ftp.software.ibm.com/ps/products/warpzilla/nspr4.zip
>
> 3. We have modified some of the flags used in the build. We have added
> the /Gx flag when we compile C++. Because Mozilla does not use C++
> exceptions, this is not needed, and it reduces code size. Also, we have
> added the /G5 flag in NSPR - it was missing this optimization. We are
> using the /Gl function in conjunction with the /OPTFUNC flag on the
> linker to reduce code size.
>
> 4. We have fully optimized the build using the /O+ option. In doing
> this, we found at least two compiler bugs (probably more). The first one
> requires a fix for the compiler. You will know that you have this bug if
> the build hangs compiling nsMsgMD5.cpp in mailnews. The second bug has
> not been fixed at the time of this writing, so as a result, we are
> unable to optimize the mozilla/security/nss/lib/freebl directory.
>
> 5. We are using the new version of LXLITE (1.3.1) to reduce the size of
> the DLLs.
>
> Please note that THIS VERSION HAS BUGS! Some people have said it is less
> stable, and we have at least found a problem with the rounding of values
> when Document Done is displayed.
>
> Please DON'T report bugs on this in Bugzilla. Please report them here.
>
> We will continue to look at this build to get as many bugs fixed as we
> can. Most of them will be bugs in the compiler, so we will want to find
> them as soon as possible since they will most likely affect trunk builds
> as well.
>
> IMPORTANT: You CAN'T share profiles with 0.6 and later builds. Make sure
> you create a new profile to use this.
>
> Thanks for your support.
>
> Mike Kaply
> IBM
