The program is one that has been exported to an object and compiled to a native binary using polyc - the problem doesn't seem to occur when running from the repl directly (because of all the allocation that happens in compiling beforehand?) but producing a standalone binary is a goal.
So this feels like a stupid question, but can I pass runtime arguments like --minheap through the compiler, so that they're applied on startup by the binary produced by polyc? It appears that runtime-related arguments passed to poly are not retained in the binary produced by polyc from the dumped image. Chris On Fri, 2 Aug 2019, at 18:16, David Matthews wrote: > Chris, > I wonder if the problem is that it has checked that there is sufficient > space available in the heap but not that this is available as a single > contiguous area. If you want to work-around the problem you can > probably set --minheap to, say 1G. > > David > > On 31/07/2019 18:53, Chris Cannam wrote: > > I have an SML program which sometimes fails while trying to allocate an > > array of 3 million ints, with the message > > > > Run out of store - interrupting threads > > > > and an exception. > > > > This happens on one of the first substantial allocations in the program, > > near the start of its run, so there should be space available - and it only > > happens on occasional runs, and if it doesn't fail, then the rest of the > > program (which does a lot more work) runs fine. > > > > The exact size of the array being allocated doesn't seem to matter so long > > as it's reasonably large, but despite this and the fact that it's so early > > in the program, I haven't yet managed to make a simple test program with a > > similar allocation pattern that fails. > > > > The situation seems to be the same regardless of whether I use Poly/ML 5.7, > > 5.8, or current git. > > > > I compared a successful run with an unsuccessful one based on logging in > > the runtime. In both cases this allocation gets sent for a "quick GC", > > which returns failure, followed by a full GC, which runs and then either > > succeeds or fails to establish that there is enough memory available > > afterwards (via CheckForAllocation). > > > > In the "good" case, when this check comes to AllocHeapSpace, the test "if > > (space->allocationSpace)" never succeeds and we fall out of the first loop > > with currentAllocSpace == 0, defaultSpaceSize == 131072, spaceBeforeMinorGC > > == 120608, and our request for minWords == 3000001 is successfully fielded > > in the following conditional block. > > > > In the "bad" case, when this check comes to AllocHeapSpace, the "if > > (space->allocationSpace)" test succeeds once (available == 131070), then we > > fall out of the first loop with currentAllocSpace == 131072, > > defaultSpaceSize == 131072, spaceBeforeMinorGC == 120608, the following > > conditional is not entered, and we return failure from the line at the end > > of the function, causing the GC to return failure as well. > > > > If I comment out the check > > if (currentAllocSpace/* + minWords */ < spaceBeforeMinorGC) > > then it apparently always succeeds, but I can see that this is no solution > > because no GC is happening at all without it... > > > > Any suggestions for what I might look at next? > > > > > > Chris > > _______________________________________________ > > polyml mailing list > > polyml@inf.ed.ac.uk > > http://lists.inf.ed.ac.uk/mailman/listinfo/polyml > > > _______________________________________________ polyml mailing list polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
