{"action":"created","issue":{"url":"https://api.github.com/repos/chaos4ever/chaos/issues/4","labels_url":"https://api.github.com/repos/chaos4ever/chaos/issues/4/labels{/name}","comments_url":"https://api.github.com/repos/chaos4ever/chaos/issues/4/comments","events_url":"https://api.github.com/repos/chaos4ever/chaos/issues/4/events","html_url":"https://github.com/chaos4ever/chaos/issues/4","id":15470474,"number":4,"title":"Try to fix the memory allocation to not leak memory","user":{"login":"perlun","id":630613,"avatar_url":"https://avatars.githubusercontent.com/u/630613?v=3","gravatar_id":"","url":"https://api.github.com/users/perlun","html_url":"https://github.com/perlun","followers_url":"https://api.github.com/users/perlun/followers","following_url":"https://api.github.com/users/perlun/following{/other_user}","gists_url":"https://api.github.com/users/perlun/gists{/gist_id}","starred_url":"https://api.github.com/users/perlun/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/perlun/subscriptions","organizations_url":"https://api.github.com/users/perlun/orgs","repos_url":"https://api.github.com/users/perlun/repos","events_url":"https://api.github.com/users/perlun/events{/privacy}","received_events_url":"https://api.github.com/users/perlun/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/chaos4ever/chaos/labels/bug","name":"bug","color":"fc2929"},{"url":"https://api.github.com/repos/chaos4ever/chaos/labels/storm","name":"storm","color":"0052cc"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2013-06-12T19:53:59Z","updated_at":"2015-03-18T20:57:00Z","closed_at":null,"body":"storm G1 has some leaks at the moment, meaning that the system will eventually run out of memory. This is well-known since many years ago but hasn't been fixed since it's quite non-trivial.\r\n\r\nWhile reading [this page](http://wiki.osdev.org/Memory_Allocation) on [OSDev.org](http://www.osdev.org) today, I was thinking - maybe we should consider switching to an existing `malloc()` implementation instead of trying to be over-creative and do our own? It is in fact quite a bit of work to get it done right; we have tried but thus far failed... :)\r\n\r\nHaven't really researched any of the alternatives, but [dlmalloc](http://g.oswego.edu/dl/html/malloc.html) seems like a reasonable alternative. It was written ages ago, is well tested and is available as \"public domain\", making the licensing a non-issue."},"comment":{"url":"https://api.github.com/repos/chaos4ever/chaos/issues/comments/83173184","html_url":"https://github.com/chaos4ever/chaos/issues/4#issuecomment-83173184","issue_url":"https://api.github.com/repos/chaos4ever/chaos/issues/4","id":83173184,"user":{"login":"perlun","id":630613,"avatar_url":"https://avatars.githubusercontent.com/u/630613?v=3","gravatar_id":"","url":"https://api.github.com/users/perlun","html_url":"https://github.com/perlun","followers_url":"https://api.github.com/users/perlun/followers","following_url":"https://api.github.com/users/perlun/following{/other_user}","gists_url":"https://api.github.com/users/perlun/gists{/gist_id}","starred_url":"https://api.github.com/users/perlun/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/perlun/subscriptions","organizations_url":"https://api.github.com/users/perlun/orgs","repos_url":"https://api.github.com/users/perlun/repos","events_url":"https://api.github.com/users/perlun/events{/privacy}","received_events_url":"https://api.github.com/users/perlun/received_events","type":"User","site_admin":false},"created_at":"2015-03-18T20:57:00Z","updated_at":"2015-03-18T20:57:00Z","body":"I definitely feel this would make sense, for process-based memory allocation. We should also change to use something like [sbrk](http://linux.die.net/man/2/sbrk). Here is how I've thought it could work:\r\n\r\n1. The process has a \"segment limit\". Any access of addresses above (or below) this limit will cause a GPF, shutting the process down.\r\n2. `sbrk` will change this limit, which is needed when allocating more memory.\r\n3. `sbrk` only changes the limit. It doesn't map any pages itself. Whenever a page fault occurs, the kernel will have to find a free page and map it for the process in question. In essence, this means we will move over to lazy mapping - in other words, a process allocating 1 gigabyte of memory is basically an O(1) operation, since it's merely a matter of changing the segment limit using `sbrk`. When this memory is being used, the actual mapping (and physical page allocation) takes place.\r\n\r\nThis should make it much easier to use an existing `malloc` implementation, since this is probably quite close to how the Unix & Linux guys currently do it."}}