I've had a look at this and I can see what is wrong. Fixing it is going to be a bit more of an effort.
The lexer is tail recursive but unfortunately some transformations that the code-generator is doing remove the tail recursion. The result is that when your example is run the stack eventually fills up.
David
On 05/02/2015 05:00, Michael Norrish wrote:
(I'll attempt to attach the tgz file to this message, but if 817KB is too big and this bounces or the attachment is dropped, I'll make it available separately.)
If compiled with Poly/ML, the attached program performs abysmally on the provided testcase.sml input file. Within seconds of beginning, it attempts to allocate more memory than my machine has (16GB), and basically brings it to its knees. If compiled with mlton, the testcase doesn't seem to cause any obvious memory allocation, and finishes in less than a second.
You can also compile with Moscow ML, though I haven?t included the build instructions in the Makefile. The execution of the mosml executable doesn't seem to allocate any memory either, and it terminates cleanly (after 17s). Though slow this is still preferable to Poly/ML's behaviour.
This is with Poly/ML 5.5.2 on
Linux telemachus 3.2.0-75-generic #110-Ubuntu SMP Tue Dec 16 19:11:55 UTC 2014
x86_64 x86_64 x86_64 GNU/Linux
The Makefile generates two executables (if you have mlton and poly in your PATH): pholdeptool and mholdeptool. You can run them on the testcase, e.g.:
pholdeptool testcase.smlThe lexer code looks to me to be tail-recursive, and the program only accumulates a binary tree containing 15 strings. So it really does seem as if Poly/ML is doing something buggy.
(The program is lexing the test-case (which uncompresses to a 30MB file) in an extremely simple way, but performing a useful analysis.)
Michael
polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml