<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Thanks for you answers,<br><br>it seems that there is a problem with sbcl and linux 64-bit.<br>I noticed that this problems does not appear on my 32-bit systems only on the 64-bit systems.<br><br>If I start sbcl with --dynamic-space-size there is no effect by allocating more memory than specified - therefor I used the os-information about memory-usage. But (room) shows always a smaller amount of allocated memory. With more calls of the examples I showed before the difference between (room) and the os-information grows. (gc) has no effect - (room) shows that (gc) released some memory, but the os still shows that there wasn't released anything.<br><br><br>Best regards<br><br>Lukas<br><br><br><br>> To: elephant-devel@common-lisp.net<br>> From: killerstorm@newmail.ru<br>> Date: Fri, 5 Mar 2010 19:13:42 +0200<br>> Subject: Re: [elephant-devel] get-instances-by-value andget-instances-by-class<br>> <br>> IE> As I recall, when allocating space in the heap for new objects, SBCL <br>> will periodically<br>> IE> ask the OS for more heap memory. Even if the objects are garbage <br>> collected later,<br>> IE> the allocated memory will remain (SBCL never releases heap memory back <br>> to the<br>> IE> OS even if it isn't using most of it). It also asks for new heap space <br>> in increasingly<br>> IE> large chunks much like a hash table.<br>> <br>> SBCL allocates a memory chunk of a fixed size, but it is only reserved at <br>> the beginning -- it is a normal behaviour on Linux that memory is actually <br>> allocated only on the first write to a page. So, yes, memory usage (RSS -- <br>> Resident Set Size) grows after use, but it does not grow indefinitely. There <br>> is --dynamic-space-size option in SBCL to control heap size.<br>> <br>> It makes sense to set --dynamic-space-size to some reasonable value, and <br>> then watch if application dies of memory starvation.<br>> <br>> If it does not die, then it is not a leak. Maybe SBCL just does not feel a <br>> need to clean up weak hash table or some memory generations, and if it is <br>> within allocated heap, it has a right to keep them.<br>> <br>> IE> It's possible that some of this memory is the shared memory allocated <br>> by BDB - but that can is upper-bounded in the my-config.sexp file and should <br>> be static.<br>> <br>> It is also possible that there is a bug in Elephant, somewhere in FFI code <br>> or in functions which do foreign calls.<br>> <br>> Technically it is also possible that leak is caused by SBCL itself -- SBCL <br>> has a conservative GC, but it only is a problem in some rare situations, <br>> when you build very long lists, for example, and probably it's not a case <br>> here.<br>> <br>> ---------------------<br>> (dotimes (i 1000000)<br>> (elephant:get-instances-by-value 'd::TopicIdentificationC 'd::uri <br>> "goethe"))<br>> ;--> memory that is not released after operation 29.0 MB<br>> <br>> <br>> (dotimes (i 1000000)<br>> (elephant:get-instance-by-value 'd::TopicIdentificationC 'd::uri <br>> "goethe"))<br>> ;--> memory that is not released after operation 0.1 MB<br>> ---------------------<br>> <br>> This is pretty interesting, if indeed get-instances-by-value leak and <br>> get-instance-by-value does not, it should be easy to pinpoint the problem.<br>> <br>> How many instances does get-instances-by-value return? Is it a long list?<br>> <br>> <br>> <br>> <br>> _______________________________________________<br>> elephant-devel site list<br>> elephant-devel@common-lisp.net<br>> http://common-lisp.net/mailman/listinfo/elephant-devel<br> <br /><hr />Hol dir das Gratis-Geschenkpaket <a href='http://redirect.gimas.net/?n=M1003Win7Geschenk' target='_new'>von Windows 7 für deinen PC ab!</a></body>
</html>