I managed to get a picture of me in the blogger.com profile, so if you want to scare small children you know where to look :-).
I should decide to what conference I try to go this summer. There is debconf 5 in Helsinki (note the title "See you in hel") which is July 10 to 17. Or I could go to LSM 2005 which is in Dijon (much closer) and from July 5 to 9 and is in general a hotbed of Common Lisp activity. I'll wait a little more until the programms pan out, but after the Danish disaster of last year I doubt I can convice my wife to go to Helsinki. She wants Calabria :-).
I made almost no progress with the lazy memory allocation in sbcl. I think I know where the problem is, but I don't have enough time to check it out :-(. Also I wonder why nobody seems to care about this problem. What do you do on a 64 bit machine, do you start by allocating 2**41 bytes? Does the OS permit this? What does root think of this? Or do you want to have to select at startup how large your image might become? If not, you need lazy allocation.
3 comments:
Actually, most operating systems do lazy allocation transparently for you. It's first when you touch the allocated memory an actual memory page will be bound to your app.
Correct. The problem is not the physical memory, but the limits and requirements of the system. There are problems with ulimits, memory layout that changes between different versions and most irritating some OSses want to have the swap available to allocate the request.
This already causes a lot of problems for cmucl on debian, and will cause even more problems on the AMD64 :-(.
Living in Denmark I cannot help being curious what the "Danish disaster" was about? -- Christian Lynbech
Post a Comment