[M3devel] thread test results on Win7 64-bit

[Coleburn, Randy]

Tony et al:

On the surface, it would seem this convoluted code is doing the following:

1.       Making rd.buff appear as an "ARRAY OF Byte", vice an "ARRAY OF CHAR, so as to meet the requirements of the File.T.read interface.

2.       Limiting the buffer to be the smaller of "BIG", or the actual number of elements in rd.buff

Now, re #2, the code in FileRd seems to allocate buffers in 4096-char arrays, and BIG is 16M, so I don't quite see why the need to ensure the buffer is limited to no more than BIG, as it should never be more than 4096.

All that aside, are you concerned that the GC could be relocating rd.buff after its address is obtained and fed to the File.T.read (rd.sourceH.read) procedure?

If indeed this movement can occur, this code definitely needs to change.

How can we force the GC not to move rd.buff, or is there another "safe" way to make rd.buff appear as an "ARRAY OF Byte" to satisfy the File.T.read interface?

Buffers are allocated in line #45 as a traced reference to an ARRAY OF CHAR via:
      rd.buff := NEW(CharBuffer, BufferSize);
Yet, the ByteArrayPtr in FileRd.m3 (line 25) is an untraced reference (to an array of Byte).

Should we be allocating buffers (rd.buff) as untraced refs instead, and then explicitly freeing?  Or, is there a way to keep them as traced refs, but avoid collection/movement while being used in an unsafe manner?

Finally, there are multiple statements in the FileRd.m3 module similar to line #83 that must be dealt with (e.g., 114, 119).

Regards,
Randy Coleburn

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Wednesday, March 16, 2011 8:14 PM
To: Coleburn, Randy
Cc: m3devel
Subject: Re: [M3devel] thread test results on Win7 64-bit

This is the offending line:
On Mar 16, 2011, at 6:50 PM, Coleburn, Randy wrote:

***
*** runtime error:
***    An array subscript was out of range.
***    file "..\src\rw\FileRd.m3", line 83
***

      n := rd.sourceH.read(
             SUBARRAY(LOOPHOLE(ADR(rd.buff[0]), ByteArrayPtr)^, 0,
                      MIN (NUMBER(rd.buff^), BIG)), mayBlock := NOT dontBlock)

I am very suspicious about this...  anyone have any insights?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110317/006cbf1a/attachment-0002.html>