August 2011 - cmucl-imp - mailman3.common-lisp.net

[cmucl-imp] x86-validate.h
by Helmut Eller 31 Aug '11

31 Aug '11

Is it necessary that we reserve such large areas at startup? #define READ_ONLY_SPACE_SIZE (0x0ffff000) /* 256MB - 1 page */ #define STATIC_SPACE_SIZE (0x0ffff000) /* 256MB - 1 page */ #define BINDING_STACK_SIZE (0x07fff000) /* 128MB - 1 page */ #define CONTROL_STACK_SIZE (0x07fff000 - 8192) (about 128 MB) Why are read-only and static space so large when a core file is less than 30MB? And why do we need such huge stacks? The default stack limit for a JVM is less than 500KB. With such settings one needs at least 720MB to start. That's a problem unless overcommitting is enabled. Helmut

2 7

[cmucl-imp] Testing
by Raymond Toy 25 Aug '11

25 Aug '11

Testing for gmail. Ray

1 0

[cmucl-imp] ASDF 2.017 released
by Faré 24 Aug '11

24 Aug '11

Dear CL users, I released ASDF 2.016.3 as 2.017. (This version has been "stable" for over a month.) Please test and upon success update your implementations and distributions. Since 2.016, we have the following improvements: * ABCL: jar translation happier with recent compile-file-pathname* change. * CCL: see truenamize change below. * GCL: vain partially reverted attempts at making GCL 2.6 and 2.7 fail less. * LispWorks: use probe-file for probe-file* * RMCL: location strings are now POSIX namestrings. You can thus share configuration files and environment variables between RMCL and other Lisp implementations on same host. Use #p"" syntax when you insist on using MacOS 9 style MCL pathnames. * truenamize: happier when e.g. the *default-pathname-defaults* is #p"", which is the case notably on CCL by default, or otherwise relative. * Logical pathnames: now preserved by the source-registry's tree directive. * Upgrade: instead of unintern'ing symbols, use fmakunbound; however, treat compilation of asdf specially, by always making sure it is loaded as source before it is compiled, so that compilation is never an upgrade and never calls fmakunbound, thus ensuring functions in the continuation of compilation are always fbound. * Obsolete: dropped support for *system-cache* and get-uid. * Internals: refactored resolve-relative-location-component. * Documentation: update wrt to the location DSL. Happy Lisping! —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org When my time on earth is completed, I want to go quietly in my sleep, like my grandfather ... not screaming in terror, like his passengers.

2 1

[cmucl-imp] Type propagation for load-time-value
by Helmut Eller 21 Aug '11

21 Aug '11

I'm proposing a patch to improve type propagation for load-time-value. Sorry for the long message: Let's say we have a file bar.lisp containing: (defun bar (x y) (declare (ignore x y))) (defun fun () #'bar) (defun baz (x y) (funcall #'bar x y)) and another file foo.lisp: (defun foo (x y) (funcall (load-time-value (let ((f (funcall 'fun))) (etypecase f (function f))) t) x y)) (defun frob () (time (dotimes (i 10000000) (foo 1 2))) (time (dotimes (i 10000000) (baz 1 2)))) and then do (load (compile-file "bar.lisp")) (load (compile-file "foo.lisp")) (frob) we see that foo runs a bit slower than baz. If we repeat the same with the in-memory compiler then foo and baz run at about the same speed: (compile (defun foo (x y) (funcall (load-time-value (let ((f (funcall 'fun))) (etypecase f (function f))) t) x y))) (frob) The cause seems to be that the ir1-translator for load-time-value throws type information away when producing fasl files an so the typecheck is executed at run time. The patch does two things: 1. in the ir1-translator actually use the type and insert a truly-the form. I only touched the read-only case; not sure what can be done in the other case. 2. change compile-load-time-value a bit: look at the result type of the return node instead of looking only at the function type of the load-time-lambda. This type seems to be more precise. I left the function type thing as fallback, though it looks dubious. With the patch applied the file compiler produces the same code as the in-memory compiler. I only tested it with this example. Helmut

2 2

[cmucl-imp] maybe-finish-mapping in map-allocated-objects must be inline
by Helmut Eller 21 Aug '11

21 Aug '11

The local function MAYBE-FINISH-MAPPING in MAP-ALLOCATED-OBJECTS must be inlined otherwise the CURRENT pointer is boxed and moved into a value cell for every object. That boxing allocates something like 1MB of saps when (room t) is called with an almost empty heap and much more for if there is something on the heap. There's also a unused variable TESTED. It looks like some parts were written by a drunk :-) Helmut --- a/code/room.lisp +++ b/code/room.lisp @@ -368,7 +368,7 @@ (fixnum (sap+ current size)) (memory-size (sap+ current size))))) (setf current c)))) - (declare (inline next)) + (declare (inline next maybe-finish-mapping)) (loop (maybe-finish-mapping) (maybe-skip-page)

2 2

[cmucl-imp] No snapshot for Aug
by Raymond Toy 05 Aug '11

05 Aug '11

For various reasons (not least of which is that my computers are on boxes), there won't be a snapshot for this month. Unfortunately, there was an important unicode fix that when in last month; that won't go in until next month. Ray

1 0