>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 06:37 PM 4/24/2001 -0500, David L. Nicol wrote:
>> Uri Guttman wrote:
>>
>> > i was looking at dan's PMC arena allocator struct and it reminded me of
>> > something an older language can do (which MJD has likened to an early
>> > perl :). ever heard of AREA in PL/I? it was a large chunk of ram
>> > dedicated to allocate memory from. what was special is that all pointers
>> > generated by these malloc calls (i forget the pl/1 syntax but it doesn't
>> > matter) were OFFSETS into the area and not direct pointers. the reason
>> > for this was that you can make a complex tree structure out of this AREA
>> > and then write the whole thing to disk as a single chunk, and in another
>> > program read it back in and your structure is back. since all the
>> > pointers are relative to the base of the AREA, you can read it back into
>> > any address in your virtual space.
>>
DS> I'm not sure we'll do either. It's a neat idea, but at the moment
DS> things are multi-tiered enough that I'm not sure it'll work
DS> without enough extra effort that'll make a plain general-purpose
DS> serialization better.
well, i am glad to see that some people actually read this amidst the
. noise.
there are many problems with my idea, particularly with syntax. in PL/I
there is only 1 way to malloc storage so you can control the syntax
easily and say this chunk/structure is coming from this area. IIRC you
declared a special pointer BASED on the AREA and you did a malloc type
call with the pointer and size as arguments and the pointer would be set
with the address (offset from the AREA base, of course) of the new chunk.
in perl, there are countless ways to allocate memory so forcing a syntax
on all of those will be almost impossible. e.g. if an array is inside an
area, it must be reallocated from there when resized and then all the
offset pointers to it must be updated. maybe arrays/hashes/strings
inside an area could be restricted from being resized? nah, nobody would
like that. PL/I didn't do any of those things and you had to manage all
the storage yourself.
like i said it is a cool idea but probably too bizarre to directly
implement in perl6.
well, the real goal is persistancy, so how about this idea?
instead of using Data::Dumper and cousins to stringify a structure,
write it out and parse it back in, we provide a module which copies and
converts a structure to an area and converts all of its pointers to
offsets. then that can be written out in one binary chunk. reading it
back in and converting back to real pointers will be much simpler and
faster than any string parser. one issue is where do the offsets go? i
ran into this problem with a large DB product which cast pointers to
offsets to send data over a pipe and assumed 32 bits at all times then
we had to port it to 64 bits. oy gevalt! but if we assume a C pointer
can hold an offset and we are starting with with pointers, it could
work. also this could use the GC traversal code to scan the structure
when making the copy.
all of that could be done in a module and not be part of the core. the
data will not be portable between platforms but it will be reloadable
anywhere in memory on the same architecture.
any thoughts on that?
uri
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11
Class and Registration info: http://www.sysarch.com/perl/OOP_class.html
