From xemacs-m  Tue Apr 15 19:57:58 1997
Received: from greatdane.webnexus.com (greatdane.webnexus.com [165.227.96.3])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id TAA04903
	for <xemacs-beta@xemacs.org>; Tue, 15 Apr 1997 19:57:58 -0500 (CDT)
Received: from apprentice.silicon-sorcery.com (apprentice.silicon-sorcery.com [205.179.145.161])
	by greatdane.webnexus.com (8.8.5/8.8.5/WN-1.2) with ESMTP id RAA00544;
	Tue, 15 Apr 1997 17:57:56 -0700 (PDT)
Received: from mage.silicon-sorcery.com (mage [128.0.0.100]) by apprentice.silicon-sorcery.com (8.7.5/8.7.3) with ESMTP id RAA23236; Tue, 15 Apr 1997 17:54:34 -0700 (PDT)
Received: (from mac@localhost)
	by mage.silicon-sorcery.com (8.8.5/8.8.5) id RAA04464;
	Tue, 15 Apr 1997 17:55:38 -0700 (PDT)
Date: Tue, 15 Apr 1997 17:55:38 -0700 (PDT)
Message-Id: <199704160055.RAA04464@mage.silicon-sorcery.com>
From: <mac@silicon-sorcery.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Hrvoje Niksic <hniksic@srce.hr>
Cc: Zlatko.Calusic@CARNet.hr, xemacs-beta@xemacs.org
Subject: Re: [comp.emacs.xemacs] Re: multi-threaded XEmacs lisp interpreter
In-Reply-To: <kig3esr964r.fsf@jagor.srce.hr>
References: <m2wwq3svck.fsf@altair.xemacs.org>
	<87k9m3zvth.fsf@atlas.infra.CARNet.hr>
	<kig3esr964r.fsf@jagor.srce.hr>
X-Mailer: VM 6.23 under 20.1 XEmacs Lucid (beta11)
Reply-To: mac@silicon-sorcery.com
X-Face:  h&j3qWe;+!`nKY~1T%IspQ[^}[s#|*2T68-NmG<hqK)^/6IlKy[e$tI,N'{!_v&R_m*f#8O
 au_+w3/b!3pF$H/]J(Q6Z)*:&Jy/.OGPM?7*<kyi}r/3Pf3hd[(J+%lmXp/;0e-EY_s2Dy{M|t


Hrvoje Niksic writes:
 > Zlatko Calusic <Zlatko.Calusic@CARNet.hr> writes:
 > 
 > > {Solaris 2.5.1 - UltraSparc} [~]% size =xemacs
 > > text    data    bss     dec     hex     filename
 > > 1122728 2038937 0       3161665 303e41  /usr/local/bin/xemacs
 > > 
 > > {Digital Unix 4.0 - Alpha} [~]% size =xemacs
 > > text    data    bss     dec     hex
 > > 2031616 3391488 0       5423104 52c000
 > >
 > 
 > Thanks.  Here are the results for XEmacs 20.1-b15, its temacs and GNU
 > Emacs 19.34 on Digital Unix 4.0:
 > 
 > {bjesomar}[~/work/xemacs-20.1-b15]$ size ./src/temacs 
 > text    data    bss     dec     hex
 > 2531328 1523712 255968  4311008 41c7e0
 > 
 > {bjesomar}[~/work/xemacs-20.1-b15]$ size ./src/xemacs    
 > text    data    bss     dec     hex
 > 2531328 3825664 0       6356992 610000
 > 
 > {bjesomar}[~/work/xemacs-20.1-b15]$ size =emacs
 > text    data    bss     dec     hex
 > 1146880 2179072 0       3325952 32c000
 > 
 > > For long time I wanted to know what's the real purpose of unexec.
 > 
 > The practical purpose of unexec is for you not to wait half-hour upon
 > each XEmacs startup. :-)  The whole XEmacs state, including all the
 > Lisp code loaded into temacs is dumped into the xemacs binary.
 > 
 > The temacs results are very important: as far as I see it, all the
 > Lisp code (some 2M) adds to the data segment, which explains why it's
 > so large for XEmacs.
 > 
 > The question is: should the preloaded Lisp code found in the data
 > segment be shared?  *Can* it be shared -- it is not read-only.
 > 
 > -- 
 > Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
 > --------------------------------+--------------------------------
 > The end of the world is coming...  SAVE YOUR BUFFERS!
 > 

	And on SunOs 4, the data is
mage 167 > size xemacs temacs
text    data    bss     dec     hex
1818624 2072576 0       3891200 3b6000  xemacs
1818624 843776  187372  2849772 2b7bec  temacs

	As you will note, the sum of bss and data is just half the
final size of the data segment.

	As the author of (or major contributer to) a number of the
unexec files, let me throw in a comment or two:

	The unexecs _can_ mark certain data pages as write protected;
curently, for example, unexsunos4.c marks the data after "environ" and
before "emacs_edata" as write protected.  If one could arrange that
the preloaded Lisp code be in a single contiguous area of the heap[1],
it is conceivable that the unexec*.c routines could copy that region
of data to a readonly section (or to text).

	However, one would have to arrange that code loaded later did
not go into that section, hence involoving answering the "Are we
dumped?" message where ever lisp file loading is done.. Also more
hassles will be incured in fixing up the relocation of that section.

	However, isn't it the case that most modern operating systems
load in initialized data pages from disk and mark them shared copy on
write? This would be the most elegant solution; as long as temacs
arranges that the lisp heap is reasonably contiguous, then all the
preloaded lisp will be in a single group of pages, which folks should
be sharing until one of them overloads a pre-dumped lisp package.

[1] a mess in itself...

