When using SaveState.saveChild to save the state, I am getting:
Timing - parse:0.0, semantics:0.0, translate:0.0, generate:0.0, run:43.7 Exception SysErr: SysErr ("Out of Memory", SOME ENOMEM) raised
Even after shareCommonData and fullGC I notice that
objSize rootFunction
returns
Timing - parse:0.0, semantics:0.0, translate:0.0, generate:0.0, run:63.4 val it = 218901122 : int
which is considerably larger than the 1382064 that is returned in a fresh poly session.
It is my understanding that the upper limit on the size of a state is determined by the resources available on a machine. Before looking into a 64 bit OS with more addressable memory etc. I wondered if it is possible to tell from the above values whether I am just trying to save something infeasibly large?
Thanks again, Phil
The information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). The information in this communication may be confidential and/or legally privileged. Nothing in this e-mail is intended to conclude a contract on behalf of QinetiQ or make QinetiQ subject to any other legally binding commitments, unless the e-mail contains an express statement to the contrary or incorporates a formal Purchase Order.
For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.
Emails and other electronic communication with QinetiQ may be monitored and recorded for business purposes including security, audit and archival purposes. Any response to this email indicates consent to this.
Telephone calls to QinetiQ may be monitored or recorded for quality control, security and other business purposes.
QinetiQ Limited Registered in England & Wales: Company Number:3796233 Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom Trading address: Cody Technology Park, Cody Building, Ively Road, Farnborough, Hampshire, GU14 0LX, United Kingdom http://www.qinetiq.com/home/notices/legal.html
Philip Clayton wrote:
When using SaveState.saveChild to save the state, I am getting:
Timing - parse:0.0, semantics:0.0, translate:0.0, generate:0.0, run:43.7 Exception SysErr: SysErr ("Out of Memory", SOME ENOMEM) raised
Even after shareCommonData and fullGC I notice that
objSize rootFunction
returns
Timing - parse:0.0, semantics:0.0, translate:0.0, generate:0.0, run:63.4 val it = 218901122 : int
which is considerably larger than the 1382064 that is returned in a fresh poly session.
It is my understanding that the upper limit on the size of a state is determined by the resources available on a machine. Before looking into a 64 bit OS with more addressable memory etc. I wondered if it is possible to tell from the above values whether I am just trying to save something infeasibly large?
Phil, Bearing in mind that the number returned is the number of words not the number of bytes then I would say that you have a problem on a 32-bit system. saveState needs to allocate enough memory on top of the existing heap to copy all the reachable data so it's quite possible that there is insufficient space. Have you checked whether you have reached the limit set by ulimit (ulimit -d) or the available swap space?
Would you expect such a large size? Is this something you've run before? It may be worth trying PolyML.objProfile to print the numbers of objects of various sizes to see whether it's what you would expect given the data structures you have.
Regards, David
David Matthews wrote:
Philip Clayton wrote:
When using SaveState.saveChild to save the state, I am getting:
Timing - parse:0.0, semantics:0.0, translate:0.0, generate:0.0, run:43.7 Exception SysErr: SysErr ("Out of Memory", SOME ENOMEM) raised
Even after shareCommonData and fullGC I notice that
objSize rootFunction
returns
Timing - parse:0.0, semantics:0.0, translate:0.0, generate:0.0, run:63.4 val it = 218901122 : int
which is considerably larger than the 1382064 that is returned in a fresh poly session.
It is my understanding that the upper limit on the size of a state is determined by the resources available on a machine. Before looking into a 64 bit OS with more addressable memory etc. I wondered if it is possible to tell from the above values whether I am just trying to save something infeasibly large?
Phil, Bearing in mind that the number returned is the number of words not the number of bytes then I would say that you have a problem on a 32-bit system. saveState needs to allocate enough memory on top of the existing heap to copy all the reachable data so it's quite possible that there is insufficient space. Have you checked whether you have reached the limit set by ulimit (ulimit -d) or the available swap space?
Would you expect such a large size? Is this something you've run before? It may be worth trying PolyML.objProfile to print the numbers of objects of various sizes to see whether it's what you would expect given the data structures you have.
David,
ulimit -d was already set to unlimited. This isn't something that we've ever managed to process before and the large size is certainly to be expected. We are processing automatically generated files and there are many known inefficiencies that are causing them to be more verbose than necessary. I was just checking in the hope that we could quickly get a particular example to work without having to address the underlying efficiency issues just yet.
Thanks, Phil
The information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). The information in this communication may be confidential and/or legally privileged. Nothing in this e-mail is intended to conclude a contract on behalf of QinetiQ or make QinetiQ subject to any other legally binding commitments, unless the e-mail contains an express statement to the contrary or incorporates a formal Purchase Order.
For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.
Emails and other electronic communication with QinetiQ may be monitored and recorded for business purposes including security, audit and archival purposes. Any response to this email indicates consent to this.
Telephone calls to QinetiQ may be monitored or recorded for quality control, security and other business purposes.
QinetiQ Limited Registered in England & Wales: Company Number:3796233 Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom Trading address: Cody Technology Park, Cody Building, Ively Road, Farnborough, Hampshire, GU14 0LX, United Kingdom http://www.qinetiq.com/home/notices/legal.html
-
David.Matthews＠prolingua.co.uk -
pclayton＠taz.qinetiq.com