[Pharo-project] Moose out of memory
Hi, There was a previous message in the list about an out of memory problem with Moose when running 3 times MooseScripts createModelForConfigurationOfMoose I downloaded moose suite 4.5 (Pharo 1.3) and played a bit with it reading the moose book (nice). IMHO although something is perhaps not completly clear in the vm in memory allocation and/or ui process and/or low space watcher (I tryed to debug the vm but did not succeed), here the problem seems to be in the Moose model. I suspect that the problem is just that the cache keeps a reference to the Moose model each time the script is run, see at the end of MooseScripts>>createModelForConfigurationOfMoose the model is added to a cache ((MooseModel root => MooseGroupRuntimeStorage>> byType) and takes abut 130M of memory each time. clearing the Moose cache resolve the problem. MooseModel allInstancesDo:[ :m | m remove ] seems to be working here, except that there is an exception for the root model (I don't know Moose, it may not be the best command). Perhaps the moose model should not be added by type but overriden each time (beeing identified by a "name" ?). PS: Moose is cool :) Cheers Alain
Alain igor fixed a problem in the windows VM. Now I do not know if this is available. Stef TX for the fix I will pass it to moosers On Jun 26, 2011, at 6:43 PM, Alain Rastoul wrote:
Hi, There was a previous message in the list about an out of memory problem with Moose when running 3 times MooseScripts createModelForConfigurationOfMoose I downloaded moose suite 4.5 (Pharo 1.3) and played a bit with it reading the moose book (nice).
IMHO although something is perhaps not completly clear in the vm in memory allocation and/or ui process and/or low space watcher (I tryed to debug the vm but did not succeed), here the problem seems to be in the Moose model. I suspect that the problem is just that the cache keeps a reference to the Moose model each time the script is run, see at the end of MooseScripts>>createModelForConfigurationOfMoose the model is added to a cache ((MooseModel root => MooseGroupRuntimeStorage>> byType) and takes abut 130M of memory each time. clearing the Moose cache resolve the problem. MooseModel allInstancesDo:[ :m | m remove ] seems to be working here, except that there is an exception for the root model (I don't know Moose, it may not be the best command). Perhaps the moose model should not be added by type but overriden each time (beeing identified by a "name" ?).
PS: Moose is cool :)
Cheers Alain
Hi, I am happy you like Moose. We know that "MooseScripts createModelForConfigurationOfMoose" creates a model that is stored in a global model cache. However, the idea was to reproduce an image that is large enough to not be openable with the Windows VM. The image with three large models opens just fine on Mac. In the meantime, Igor produced a new version of the Windows VM that enables one to load this image. However, now the question is when these fixes will make it in the main branch. Igor, do you happen to have an update on this issue? Cheers, Doru On 26 Jun 2011, at 18:43, Alain Rastoul wrote:
Hi, There was a previous message in the list about an out of memory problem with Moose when running 3 times MooseScripts createModelForConfigurationOfMoose I downloaded moose suite 4.5 (Pharo 1.3) and played a bit with it reading the moose book (nice).
IMHO although something is perhaps not completly clear in the vm in memory allocation and/or ui process and/or low space watcher (I tryed to debug the vm but did not succeed), here the problem seems to be in the Moose model. I suspect that the problem is just that the cache keeps a reference to the Moose model each time the script is run, see at the end of MooseScripts>>createModelForConfigurationOfMoose the model is added to a cache ((MooseModel root => MooseGroupRuntimeStorage>> byType) and takes abut 130M of memory each time. clearing the Moose cache resolve the problem. MooseModel allInstancesDo:[ :m | m remove ] seems to be working here, except that there is an exception for the root model (I don't know Moose, it may not be the best command). Perhaps the moose model should not be added by type but overriden each time (beeing identified by a "name" ?).
PS: Moose is cool :)
Cheers Alain
-- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."
On 26 June 2011 22:05, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I am happy you like Moose.
We know that "MooseScripts createModelForConfigurationOfMoose" creates a model that is stored in a global model cache. However, the idea was to reproduce an image that is large enough to not be openable with the Windows VM. The image with three large models opens just fine on Mac.
In the meantime, Igor produced a new version of the Windows VM that enables one to load this image. However, now the question is when these fixes will make it in the main branch.
Igor, do you happen to have an update on this issue?
I will include fix into my branch. The windows slave is now working, so there is a little to do.. push the changes and update configs. As for, whether this fix will be integrated into main branch, you asking a wrong person.
Cheers, Doru
-- Best regards, Igor Stasenko AKA sig.
Hi Igor, On 27 Jun 2011, at 18:20, Igor Stasenko wrote:
On 26 June 2011 22:05, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I am happy you like Moose.
We know that "MooseScripts createModelForConfigurationOfMoose" creates a model that is stored in a global model cache. However, the idea was to reproduce an image that is large enough to not be openable with the Windows VM. The image with three large models opens just fine on Mac.
In the meantime, Igor produced a new version of the Windows VM that enables one to load this image. However, now the question is when these fixes will make it in the main branch.
Igor, do you happen to have an update on this issue?
I will include fix into my branch. The windows slave is now working, so there is a little to do.. push the changes and update configs.
Great. I am really looking forward to getting my hands on the fixed Gog VM :)
As for, whether this fix will be integrated into main branch, you asking a wrong person.
I know, but I asked anyway :). Cheers, Doru
Cheers, Doru
-- Best regards, Igor Stasenko AKA sig.
-- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."
On Jun 27, 2011, at 6:20 PM, Igor Stasenko wrote:
On 26 June 2011 22:05, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I am happy you like Moose.
We know that "MooseScripts createModelForConfigurationOfMoose" creates a model that is stored in a global model cache. However, the idea was to reproduce an image that is large enough to not be openable with the Windows VM. The image with three large models opens just fine on Mac.
In the meantime, Igor produced a new version of the Windows VM that enables one to load this image. However, now the question is when these fixes will make it in the main branch.
Igor, do you happen to have an update on this issue?
I will include fix into my branch. The windows slave is now working,
Really? Excellllllent! After all this fight.
so there is a little to do.. push the changes and update configs.
As for, whether this fix will be integrated into main branch, you asking a wrong person.
Cheers, Doru
-- Best regards, Igor Stasenko AKA sig.
On 27 June 2011 22:39, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jun 27, 2011, at 6:20 PM, Igor Stasenko wrote:
On 26 June 2011 22:05, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I am happy you like Moose.
We know that "MooseScripts createModelForConfigurationOfMoose" creates a model that is stored in a global model cache. However, the idea was to reproduce an image that is large enough to not be openable with the Windows VM. The image with three large models opens just fine on Mac.
In the meantime, Igor produced a new version of the Windows VM that enables one to load this image. However, now the question is when these fixes will make it in the main branch.
Igor, do you happen to have an update on this issue?
I will include fix into my branch. The windows slave is now working,
Really?
Excellllllent! After all this fight.
Yes, after some voodoo spells, today i got a VM built. Good to know that process are really reproducable: built once using git+config on my machine locally ==> repeating the same without problems on hudson slave. Except that setup is a bit different (tools, installs, paths, Windows idiosyncrazy etc etc) and i had to fix it before everything could start running. -- Best regards, Igor Stasenko AKA sig.
Yes, after some voodoo spells, today i got a VM built.
Good to know that process are really reproducable: built once using git+config on my machine locally ==> repeating the same without problems on hudson slave. Except that setup is a bit different (tools, installs, paths, Windows idiosyncrazy etc etc) and i had to fix it before everything could start running.
I'm happy :) You see I'm simple :) Stef
Thanks I missed the point about the moose error. Good news for the vm fixes, I missed Igor posts too :( Cheers Alain "Tudor Girba" <tudor@tudorgirba.com> a écrit dans le message de news: 15309023-B13B-42A2-97A4-CED5D0FEFF56@tudorgirba.com... Hi, I am happy you like Moose. We know that "MooseScripts createModelForConfigurationOfMoose" creates a model that is stored in a global model cache. However, the idea was to reproduce an image that is large enough to not be openable with the Windows VM. The image with three large models opens just fine on Mac. In the meantime, Igor produced a new version of the Windows VM that enables one to load this image. However, now the question is when these fixes will make it in the main branch. Igor, do you happen to have an update on this issue? Cheers, Doru On 26 Jun 2011, at 18:43, Alain Rastoul wrote:
Hi, There was a previous message in the list about an out of memory problem with Moose when running 3 times MooseScripts createModelForConfigurationOfMoose I downloaded moose suite 4.5 (Pharo 1.3) and played a bit with it reading the moose book (nice).
IMHO although something is perhaps not completly clear in the vm in memory allocation and/or ui process and/or low space watcher (I tryed to debug the vm but did not succeed), here the problem seems to be in the Moose model. I suspect that the problem is just that the cache keeps a reference to the Moose model each time the script is run, see at the end of MooseScripts>>createModelForConfigurationOfMoose the model is added to a cache ((MooseModel root => MooseGroupRuntimeStorage>> byType) and takes abut 130M of memory each time. clearing the Moose cache resolve the problem. MooseModel allInstancesDo:[ :m | m remove ] seems to be working here, except that there is an exception for the root model (I don't know Moose, it may not be the best command). Perhaps the moose model should not be added by type but overriden each time (beeing identified by a "name" ?).
PS: Moose is cool :)
Cheers Alain
-- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."
participants (4)
-
Alain Rastoul -
Igor Stasenko -
Stéphane Ducasse -
Tudor Girba