From:	MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX"  7-OCT-1992 23:30:53.50
To:	info-vax@kl.sri.com
CC:	
Subj:	Re: Why is demand-zero compression for shareable images unsupported?


Lots of people have been asking about demand-zero compression in shareable
images and why one needs UNSUPPORTED=1 in the options file to turn it
on.  Here's the real story.

Prior to VMS V3.0, there was only one RTL shareable image, VMSRTL.  This
image contained support for the FORTRAN, BASIC and COBOL languages, plus
the LIB$, MTH$, OTS$ and STR$ facilities.  In 1982 (or thereabouts), I
had the task of implementing the "breakup" of VMSRTL into the five
shareable images LIBRTL, MTHRTL, BASRTL, COBRTL and FORRTL.  This was
made possible by a lot of work in the linker (done by Benn Schreiber, if
I recall), to allow a shareable image to reference other shareable images
it hadn't when the executable was originally linked.  (This is pretty much
beside the point, but it's part of the story.)

Anyway, none of these shareable images had demand-zero sections; they
did have read/write data, but they were initialized.  During the field
test of VMS V3, it was realized that LIBRTL's image activation was a
significant chunk othe total activation time for most images, and that
a lot of this came from the copy-on-reference read/write section.  So
LIBRTL was modified to not have any initialized data so that the
read/write section would be demand-zero, and the linker modified to
create demand-zero sections for shareable images (which it hadn't
before.)  This worked great and everyone was happy.  Until...

Until someone linked a shareable image with what was now a demand-zero
section and installed it /WRITE!  Perfectly reasonable thing to do,
except - what did this mean?  A big mess, that's what!  There was a
flurry of discussion, but time was tight (the change had been introduced
in the last field-test update), we didn't want to go back to
copy-on-reference for LIBRTL, so the chosen solution was to add an
undocumented and aptly named linker option to turn on the feature.  You
were to use it only if your read-write PSECTs were not SHR and GBL.
We only used it for LIBRTL and VMS V3 went out the door.

Ok, but now it's ten years later and we're still stuck with UNSUPPORTED=1.
This problem has not been forgotten, and a number of solutions have
been proposed, but it "works" now, even if it's undocumented, and fixing
this has always been rather low on the priority lists.  Still, the
discussion resurrects itself from time to time, and I think I will
bring it up again to the VMS devos to see if some sort of closure can
be reached.  A DECUS SIR (Software Improvement Request) would also be
helpful, as these get high visibility.

Please note that the opinions I expressed here are my own and do not
reflect an official position of my employer.  (I've always wanted to
write one of these disclaimers, and I think I had better this time.)

Steve Lionel                    lionel@quark.enet.dec.com
SDT Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062