Hrvoje Niksic <hniksic(a)srce.hr&gt; writes: We are using different meanings for the word "use" here. I'll try to clarify what I mean (feel fry to correct me where I am wrong. Hoewever I think I understand what happens). A. XEmacs has 2 spaces for allocating storage: Pure and Normal. Pure space allocations is are allowed in temacs. Moreover, In 'xemacs' we check carefully not to write to purespace. B. The OS is told that the pure space is read only. Of course one can only safely do B if we do A. If we did not check for writes to purespace we would segfault. I am claiming that on ELF-systems we do A but we do NOT do B. The reason we want(ed) to do B was that it used to be that only section that were read only were shared. However on ELF systems parts of the executable that were never written to are _always_ shared[1]. Read-only or not. So it is not a problem that we do not do B. The techniques used by ELF systems to allow the pages to be shared are more or less the same (pagefaulting) as you propose to replace the 'purefied?' test with. However if the pure space writeable (not B) it is unnecessary to do the test (A) anyway. So I think you are wasting your time. Because on ELF systems pure space is writable. I object to the term "hosed" here. It is a feature that X[AC]DR being an lvalue does not crash. The only loss here is that on some systems (most notably Kyle's as he is using an a.out system) it will crash. Therefore these bugs do not get caught until the code is used on such a system. However I propose another solution to that, see later. Yes. But on ELF systems purespace is shared EVEN IF IT IS WRITABLE[1]. We want sharing, 'read-only' is only an unfortunate consequence of that. We already DO COW. Only we have to it by hand. If you want set-car on a pure cons you have to copy it to normal storage first. That is copying "before" write. You get that for free on modern Unixen. So how do we solve the problem without forcing Kyle to move to an ELF machine. Let's have a look at the purespace stats from 21.0: Purespace usage: 770008 of 770012 (100%). Total Bytes cons cells: 11236 89888 12% float objects: 19 304 0% symbol-name strings: 8690 226852 29% compiled-function objects: 2245 62860 8% byte-code strings: 2245 183096 24% byte-constant vectors: 2245 97824 13% interactive strings: 294 6368 1% documentation strings: 1 132 0% other function strings: 2132 73420 10% other vectors: 326 8124 1% other strings: 486 21124 3% all strings: 13848 510992 66% all vectors: 2571 105948 14% That is: only 90K of pure space is cons cells. I propose we just no longer use pure space for cons cells. If we keep using for the rest we still have 88% of the savings. So the tradeoff is between 1. losing 90K of shared pages on some systems (non-ELF). 2. A function call (the default gcc '-O2' flag does not inline code) when using XCAR and XCDR or equivalent as an lvalue. So is 2. worth it? Footnotes: [1] My whole argument is based on this. If somebody know this is not true, please speak up. -- Jan Vroonhof http://www.math.ethz.ch/~vroonhof/ Mathematik, vroonhof ＠ math.ethz.ch HG E16, ETH-Zentrum, Tel: +41-1-6325456/25154 Raemistrasse 101, CH-8092 Zuerich. Fax: +41-1-6321085