Title search engines should release memory when destroyed
Priority feature Status reviewing
Superseder Nosy List erez, malte, patrik
Assigned To erez Keywords
Optional summary

Created on 2011-04-12.09:05:55 by patrik, last changed by malte.

msg2401 (view) Author: malte Date: 2013-03-13.16:50:52
Long time no action on this front. I suggest to defer working on this until
issue344 is resolved.
msg1410 (view) Author: erez Date: 2011-06-30.12:45:03
The fix is now pushed into my downward-fixes repository.
I also fixed another issue I found, where LAMA-FF Synergy did not support the 
reset() method (to clear landmark information).
msg1406 (view) Author: erez Date: 2011-06-30.10:24:53
Ok, I'll start working on it.
msg1405 (view) Author: malte Date: 2011-06-30.10:16:57
I wouldn't be worried about destructors taking too much time. If it indeed turns
out that they do, we can do something about it then. So the suggestion sounds
good to me, and I wouldn't add an option -- searches should always clean up
after themselves.

It's part of a more general problem we have where things are allocated and then
not deleted due to laziness and the now ill-founded assumption that they will
persist until the end of the planner's lifetime anyway. So once this is
addressed, I'd like to see a separate issue about memory deallocation in
general. (Might as well open it now already, of course.)
msg1403 (view) Author: patrik Date: 2011-06-30.09:28:59
It's only expensive if the destructor is actually invoked, right. And since it
all starts with IteratedSearch deleting it's current search, you could use an
option (to iterated_search) to control if you want it to do this or not. If it
doesn't, then none of the recursive destruction (search space, open lists, etc)
takes place, and overhead should be minimal.
msg1399 (view) Author: erez Date: 2011-06-30.08:35:15
Just saw this (I should go over the issue tracker more often).
I think it's worth doing (even though I know that deleting the old searches might 
take a considerable amount of time).
Any objections?
msg1326 (view) Author: patrik Date: 2011-04-13.11:38:54
Nevermind, I think I've sorted this out.

In case anyone's interested:

- IteratedSearch::step needs to delete current_search;
- Search engine destructors need to delete their open list;
- AlternationOpenList's destructor needs to delete the sublists;
- SearchSpace's destructor (or someone) must delete the copies made of states by

For the last point, I did a two-step thing that first iterates through the hash
table, collecting the state pointers in a vector, then deletes the hash table
and finally runs through the vector deleting the states. Directly deleting the
states while iterating through the hash table caused a segfault.

(I'm downgrading this to a "wish", on the basis that it might be nice if this
was done properly in some future version... ;))
msg1325 (view) Author: patrik Date: 2011-04-12.09:05:54
I'm not sure if this is a bug, a feature, or just a stupid question.

I'm doing some experiments with repeated, randomised search, using FD. For this
purpose, I've added some randomisation to the FF heuristic (when there are
several min cost supporters for a proposition, one is chosen randomly) and to
lazy_search (very similar to the succ_mode == shuffled option that was already
there, but shuffling the preferred and non-preferred successors separately, and
placing the preferred ones first). To run repeated searches, I'm using the
iterated_search engine, as follows:

iterated(lazy_greedy(hff, succ_mode=3, preferred=(hff)), pass_bound=false,

that is, I want the search to start "fresh" (no passing of bounds) in each
iteration. However, it seems that something is kept in memory between searches,
because memory use grows continually, and very rapidly. Are old "phase" engines
not deleted? (If not, some hints as to where/how I should modify iterated search
to do that would be highly appreciated...) Or is some information, like the
closed list, kept between searches?
Date User Action Args
2013-03-13 16:50:52maltesetmessages: + msg2401
2011-06-30 12:45:03erezsetstatus: in-progress -> reviewing
messages: + msg1410
2011-06-30 10:24:53erezsetstatus: chatting -> in-progress
priority: wish -> feature
messages: + msg1406
2011-06-30 10:16:57maltesetmessages: + msg1405
title: Caching in iterated search -> search engines should release memory when destroyed
2011-06-30 09:28:59patriksetmessages: + msg1403
2011-06-30 08:35:15erezsetassignedto: erez
messages: + msg1399
nosy: + erez
2011-04-27 10:48:56maltesetnosy: + malte
2011-04-13 11:38:54patriksetpriority: bug -> wish
status: unread -> chatting
messages: + msg1326
2011-04-12 09:05:55patrikcreate