YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> writes: >>>>>> On Sun, 13 Nov 2005 23:54:29 -0500, "Richard M. Stallman" <[EMAIL >>>>>> PROTECTED]> said: > >>> So, if there's a non-pure object that is only pointed to by pure >>> objects, which may happen if the assumption for the pure storage is >>> violated, then the object is reachable but get collected. > >> Is there evidence that this is in fact happening? > > David (and others) are distributing precompiled GNU Emacs binaries > with additional files preloaded. And they see a problem (so-called > "commandp" one) which I don't see with the CVS version. I suspect > this is due to the situation above, but there's no evidence yet. > >> If so, can you see a general rule for how to prevent it from >> happening? > > I think compile-time analysis would not become perfect because of > dynamic bindings. > > On some systems including Mac OS X, the pure storage is not remapped > to the text segment. But still one can set watchpoint to the array > `pure' to do run-time check. I think it is sufficient if additional > preloading is for developers/power-users rather than for ordinary > users.
It seems to be possible to have a check_pure_storage function which would traverse pure storage and validate that it only refers to other pure object -- and also that pure storage only contains valid objects (e.g. I don't think storing a buffer or window object in pure storage makes any sense). This function only needed to be run once during the build process, e.g. just before undump. -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk _______________________________________________ Emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
