Well we're on the way! With caveat you can't use a Judy array
or anything with a custom scanner yet, we can now find
the pointer closure of a given pointer:
//////////////////////
var li = list("hello","my","World");
var pts = Serialise::find_closure li.C_hack::cast[address];
println$ pts;
var li2 = list (li, list("my","sweat","lord"), list("janis","joplin"));
var pts2 = Serialise::find_closure li2.C_hack::cast[address];
println$ pts2;
////////////////////
list(0x100101ec0, 0x100101e70, 0x100101ab0, 0x0)
list(0x100103230, 0x100103220, 0x100103110, 0x1001030e0, 0x1001030b0,
0x100102b70, 0x100102b40, 0x100101ec0, 0x100101e70, 0x100101d10, 0x100101ab0,
0x0)
/////////////////////////
Not 100% sure it works but the number of objects seems correct :)
Not clear the NULL pointer should be in there. I think the routine
collects foreign pointers too but (probably) shouldn't.
It's fairly simple now to just serialise the lot of these objects
and concatenate the serialisations. Decoding is easy enough too.
There are some things not fully handled yet but known about:
unions used tagged pointers, and we have to make sure if the
tag is in the low 2 bits of the pointer those bits aren't lost.
There is however a more serious issue here. The Judy array
scanners assume both the key and value, if they're words,
are pointers. This is wasteful if either is long integer instead.
For GC, if we happen accidentally to pick up an integer
with the same value as a pointer, it won't be reaped,
and so won't be finalised, but that's the worst of it:
no major damage.
For serialisation, compaction, and other such routines,
precision is mandatory. It really DOES matter if you serialise
and object whose address just happened to be the same
as an integer in a slot which might hold either a pointer
or an integer, and then on rebuilding the containing object
you CHANGE the integer to "point to the new object" when
it was an integer, not a pointer.
The confusion between Felix pointers and Foreign (C) pointers
is no problem, because they cannot clash. By this I mean,
a pointer slot in an object the GC knows about can safely
hold either a Felix pointer or a C pointer. The C pointer
won't be tracked (because there's no associated rtti object).
In particular, pointers to Felix objects on the machine stack
also won't be tracked either. (Only heap allocated objects
can be tracked).
This means more work writing scanners for the different
kinds of Judy arrays eg for JudyL there are four scanners:
key is pointer? Yes/no Data is pointer? Yes/no
Similarly a C++ vector of "intptr_t" has two variants,
depending on whether its a vector of pointers or
a vector of integers.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
