typo, read/write should be
c_read=: 'read x i * x' api
c_write=: 'write x i * x' api
bill lam wrote:
I check c header files, the signature for 32/64 bit should be,
c_isatty=: ' isatty i i' api
c_open=: 'open i *c i i' api
c_close=: 'close i i' api
c_read=: 'read i i * i' api
c_write=: 'write i i * i' api
c_lseek=: 'lseek x i x i' api
c_mmap=: 'mmap * * x i i i x' api
c_munmap=: 'munmap i * x' api
I test map a 2000GB file and no error on my 64-bit ubuntu
createjmf_jmf_ '/tmp/large'; 2000 * 1024(<[EMAIL PROTECTED])3
map_jmf_ 'largenoun';'/tmp/large'
The file created is sparse, only i-node is allocated at this stage. My
hard-disk is very small, so that I cannot do real-life testing.
What linux do you use?
Jorge Arredondo wrote:
I'm not using jmf.ijs definitions for this test case, but the ones I
posted in the first message
(http://www.jsoftware.com/pipermail/programming/2008-March/010309.html).
I did change some i in signature to x or l.
Setting an absolute path for libc.so.6 doesn't make any difference in
the test, since 15!:0 would raise a domain error when trying to call a
32-bit DLL from a 64-bit process, anyway, I tested with the following
definitions and I still face the 9GB limitation:
c_open=: '/lib64/libc.so.6 open64 i *c i i'&cd
c_close=: '/lib64/libc.so.6 close i i'&cd
c_lseek=: '/lib64/libc.so.6 lseek64 i i l i'&cd
c_write=: '/lib64/libc.so.6 write i i * i'&cd
c_mmap=: '/lib64/libc.so.6 mmap64 * * x i i i l'&cd
c_munmap=: '/lib64/libc.so.6 munmap i * x'&cd
On Wed, Apr 9, 2008 at 9:35 AM, bill lam <[EMAIL PROTECTED]> wrote:
Assuming using a 64-bit version, some i in signature should be
changed to x
in eg, c_lseek=: 'lseek i i i i' api
Did you get the changed done or can shared it with us?
find_dll need some work in 64-bit Linux. because there are both 32
and 64
bit library installed, eg there are /lib /lib32 /lib64 , so you may
want to
check
the file 'libc.so.6' (without absolute path) returned by find_dll
'c' is
actually a 64-bit libc.so.6
Jorge Arredondo wrote:
I tried your suggestion about ulimit, and changing -v to "unlimited"
actually increased the maximum file size I can mmap to 9GB, however
this is still far from the 200GB file I can mmap in Windows. There
might be another setting that must be changed in order to get rid of
this limitation.
Kernel tuning seems to be the best solution, since breaking the file
into smaller pieces would require extra --and complex-- code to handle
such pieces as a whole array.
On Tue, Apr 8, 2008 at 5:37 PM, Raul Miller <[EMAIL PROTECTED]>
wrote:
On 4/8/08, Jorge Arredondo <[EMAIL PROTECTED]> wrote:
> mmap(NULL, 8589935160, PROT_READ, MAP_SHARED, 4, 0) = -1 ENOMEM
> (Cannot allocate memory)
http://www.linux.org/docs/ldp/howto/SCSI-Generic-HOWTO/errors.html
http://www.irccrew.org/~cras/security/howto/dynamic.html
It looks like linux is not designed to mmap large files, by default.
You might be able to tune your kernel, or you might have to
break the file down into smaller pieces (or hope that some day
J will introduce a bunch of complex code to work around this
problem).
But the first thing to check is whether whether ulimit -a says that
you have any memory limits active.
--
Raul
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
