[MLton-devel] Windows port (D2) problem

[Stephen Weeks]

Alain wrote:
> We finally started working on the Windows port.
> 
> We have a problem with the enclosed code, which executes correctly
> under Linux but fails an internal test when cross-compiled to
> Windows.
> 
> I made sure the Cygwin DLL we use is the one you recommend
> (1.3.11).
> 
> My Linux command line is :
> % mlton -exn-history true -safe true -o crash.exe -host \
>   i386-pc-cygwin -v crash.sml
> 
> First problem.
> --------------
> The Windows launching command is:
> % ./crash.exe 30000
> 
> This produces a raise Match at line 6209 of the source file: which
> is triggered by a consistency test: we build a hashtable, dump it
> to disk, undump it, and then check that the number of items is the
> same. I got: 990001 versus 989994.
> 
> This works fine under Linux. 

This is due to a \r\n problem.  On linux, the dumped file is of size
9,399,925, while on windows, it is of size 9,445,998, so the windows
file is 46,073 bytes larger.  Each file has 46,291 \n's.  There are
218 \r\n's in the file that your program writes.  So, the difference
is that windows has inserted an additional 46,073 \r's before the \n's
that don't have a preceeding \r.  This happens because you are use
TextIO, which opens the file in text mode, which does nothing on
linux, but on windows converts \n to \r\n when writing and \r\n to \n
when reading.  Since windows can't tell the difference between the
\r\n's that your program wrote and the \r\n's that it inserted, your
program never only sees \n when it wrote \r\n.  Hence you get fewer
records.  

The only solution that I see is to use BinIO (a recent addition to
MLton) instead of TextIO.  This will open the file in binary mode on
windows, which will prevent \r\n conversion.

> Second problem.
> ---------------
> The Windows launching command is:
> % ./crash.exe 3000
> 
> The above dump/undump test does work. However, this fails during
> GC on a 512Mb array by saying:
> 
> > Out of memory (forward).
> > size=512000008 .. s->fromSize=640860160 s->toSize=6291456
> > ...
> 
> Again, this works fine under Linux.
> 
> My Windows machine is equipped with Windows 2000 and has 512Mb
> RAM.

Does this happen with MLton 20020410 as well?  There were some changes
on April 3 to improve memory usage that I am pretty sure went into
20020403, but I am not positive.

What is the size of your windows swap file?  It appears that the MLton
runtime is already using 640,860,160 bytes, which is more than RAM.
Maybe there isn't enough virtual memory?  That's what it looks like,
since MLton was only able to allocate 6,291,456 bytes for toSpace.  If
at all possible, the runtime attempts to have toSpace larger than
fromSpace.  Only if it is not able to get enough space does it then
attempt the GC with a smaller toSpace -- of course, then the GC may
fail, as it did here.

_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel