Phil,
Thank you for testing this and reporting the problem. It actually
turned out to be a bug in the compact 32-bit version. The compilation
happened to allocate an array of a particular size that was wrongly
copied in the minor garbage collection resulting in a crash either in
the GC itself or later on. I've pushed a fix to master and I'm copying
this message to the mailing list since this represents a change that
others may need to be aware of.
Regards,
David
On 03/03/2019 00:27, Phil Clayton wrote:
David,
I have been trying out the latest candidate for Poly/ML 5.8 (c3a630f)
with --enable-compact32bit and have not found any issues. I was pleased
to see a space saving with saved state files, which appear to be around
62-68% of their size compared with not using compact32bit. I haven't
measured any other performance though.
In one obscure respect, compact32bit fails where the full 64 bit version
does not: the exponential blow-up described in this example from a few
years ago now fails to compile code where the full 64 bit version would
take around 8 s on my machine. Presumably some internal limit is hit
sooner with 32 bits. I have seen two different failure messages as
shown in the following log.
Regards,
Phil
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
