After integrating the new Finalizable module in a library, I am getting an internal error from the compiler:
Exception- InternalError: AllocStore found but last allocation not complete raised while compiling
This affects Poly/ML 5.5.2 and the very latest commit with the compiler rebuilt (twice). An example is attached showing this. I have reduced this as far as I can but still a few small library files are required. The file 'polyml.sml' is the top-level file that uses the other files.
Regards, Phil
On 22/09/2015 19:00, Phil Clayton wrote:
After integrating the new Finalizable module in a library, I am getting an internal error from the compiler:
Exception- InternalError: AllocStore found but last allocation not complete raised while compiling
Thanks for reporting this and cutting it down to a suitable example. I've tracked down the problem and committed a fix.
As a shameless plug for the newly updated debugger, I used that to set a breakpoint on the exception and then it was easy to see what was going on. The new debugger is a great deal faster than the old version so it's perfectly feasible to build the whole compiler with debugging enabled.
One other point, when trying to cut examples down to the smallest case that demonstrates a bug, it's worth playing with PolyML.Compiler.maxInlineSize. It's often the case that a bug only shows up when an example is large enough that it isn't inlined so setting this to something small, e.g. 1, may allow more of the surrounding code to be pruned away.
David
24/09/15 08:44, David Matthews wrote:
On 22/09/2015 19:00, Phil Clayton wrote:
After integrating the new Finalizable module in a library, I am getting an internal error from the compiler:
Exception- InternalError: AllocStore found but last allocation not complete raised while compiling
Thanks for reporting this and cutting it down to a suitable example. I've tracked down the problem and committed a fix.
Thanks - this works with the latest commit.
As a shameless plug for the newly updated debugger, I used that to set a breakpoint on the exception and then it was easy to see what was going on. The new debugger is a great deal faster than the old version so it's perfectly feasible to build the whole compiler with debugging enabled.
I tried the debugger many years ago but it couldn't cope with large examples. I seem to recall that compiling with PolyML.Compiler.debug set to true sometimes failed. I'll give it another go sometime.
I just had a quick look at the tutorial. How do you exit from the debug prompt? (Ctrl+C didn't work.)
One other point, when trying to cut examples down to the smallest case that demonstrates a bug, it's worth playing with PolyML.Compiler.maxInlineSize. It's often the case that a bug only shows up when an example is large enough that it isn't inlined so setting this to something small, e.g. 1, may allow more of the surrounding code to be pruned away.
That's useful to know. I checked the latest commit with maxInlineSize set to 1 and it still compiles.
I was hopeful that increasing maxInlineSize would provide a work-around for 5.5.2. It does, by setting maxInlineSize to 175, but at the expense of much longer compilation times - see the tables below. Also, the executable size of the example is much larger with 5.5.3. Is that expected?
Phil
The columns below show 1. PolyML.Compiler.maxInlineSize 2. real|user|sys times 3. helloworld executable size
5.5.2
160 fails 170 fails 175 1m14.032s|1m22.092s|0m3.807s 290122 180 1m13.523s|1m21.813s|0m3.728s 290122 200 1m14.671s|1m23.267s|0m3.684s 290122 240 1m15.493s|1m22.855s|0m3.736s 290944 320 1m20.699s|1m30.642s|0m4.133s 283650
5.5.3 (5dc43ce8e8eaaae7...)
1 0m11.476s|0m13.651s|0m1.470s 912681 80 0m18.673s|0m22.754s|0m2.071s 882459 120 0m16.855s|0m19.518s|0m1.770s 893577 160 0m30.113s|0m39.925s|0m3.004s 923681 170 0m30.687s|0m40.661s|0m2.948s 923575 175 1m20.665s|1m41.830s|0m5.302s 923589 180 1m18.039s|1m34.776s|0m4.183s 923589
On 27/09/2015 15:20, Phil Clayton wrote:
24/09/15 08:44, David Matthews wrote:
On 22/09/2015 19:00, Phil Clayton wrote: As a shameless plug for the newly updated debugger, I used that to set a breakpoint on the exception and then it was easy to see what was going on. The new debugger is a great deal faster than the old version so it's perfectly feasible to build the whole compiler with debugging enabled.
I tried the debugger many years ago but it couldn't cope with large examples. I seem to recall that compiling with PolyML.Compiler.debug set to true sometimes failed. I'll give it another go sometime.
I just had a quick look at the tutorial. How do you exit from the debug prompt? (Ctrl+C didn't work.)
I've just done some timings with the new debugger and the old one. Building the compiler with debugging enabled with the new version is roughly 8 times slower. With the old version it was approximately 100 times slower! Note that to get the advantage with the version in git it's necessary to run "make compiler".
At the moment to exit the debug prompt you need to continue the debuggee with "continue" or "continueWithEx". The latter is often the easiest way but it needs to be with an exception that isn't handled by the debuggee or by an exception break-point (breakEx exn).
I've wondered about whether there should be a way to simply discard the current debuggee completely. The only way I can see to do that would be to run every top-level expression as a new thread with the REPL waiting for that thread to complete. The top-level doesn't know when it starts running something that it contains debugging code.
One other point, when trying to cut examples down to the smallest case that demonstrates a bug, it's worth playing with PolyML.Compiler.maxInlineSize. It's often the case that a bug only shows up when an example is large enough that it isn't inlined so setting this to something small, e.g. 1, may allow more of the surrounding code to be pruned away.
That's useful to know. I checked the latest commit with maxInlineSize set to 1 and it still compiles.
I was hopeful that increasing maxInlineSize would provide a work-around for 5.5.2. It does, by setting maxInlineSize to 175, but at the expense of much longer compilation times - see the tables below. Also, the executable size of the example is much larger with 5.5.3. Is that expected?
There have been quite a few changes to the compiler that may increase the size of the executable and I'd have to look carefully to see exactly why it has affected that particular example.
David
-
David.Matthews＠prolingua.co.uk -
phil.clayton＠lineone.net