On Fri, Feb 04, 2005 at 12:14:31PM +0100, Fr?d?ric Gava wrote:
> >It's a problem of the implementation, but one which looks hard to
> >change.  The reason it arises is because each OCaml value has a 4
> >byte[*] header, divided into a 1 byte tag, 2 bits for the GC, and the
> >remaining 22 bits to store the size of the value in words.  Since
> >strings are stored directly in the value (which is very efficient),
> >they are limited to 4 * (2^22 - 1) bytes ~ 16 MB in size.
> Sure it is a hard problem. But I thinks that in the futur (now my bench are
> not bench of true applications but bench of the limits of the language,
> values that exceed 16Mo are rare), true scientific applications will need to
> serialize big values...(big graphs for example)

I've been thinking about this a bit more, and I'm not sure I
understand why the tag needs to be so large.  If you look at the "tag
space" now, it's something like this:

0	used for tuples, arrays, records
1-251	used for constructors (eg. Some, None)
252	marks strings
253 	marks floats
254	marks float arrays
255	marks structures with custom ops (lots of stuff, like Int32.t)

It's not clear to me why so much "tag space" is used for constructed
values, at the same time limiting you to around 250 different
constructors in a type definition.  Couldn't the constructor number be
encoded in the first field in the value (obviously shifting all the
subsequent fields along one, and making constructed values 4 bytes
larger)?  Then the tag could be reduced to a few bits, making strings
a few orders larger.

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com