in reply to Re: Circular reference testing.
in thread Circular reference testing.

... to numify a reference to something other than an actual memory address ...

That would tend to invalidate the mechanisms (mostly using hashes), in use by existing modules also?

... whether Ponie is already planning to break either ...

In the non-reference counting, brave new world of mark&sweep GC, it probably will break it, but it begs requires the question of whether there will be some mechanism for asking the VM about circular references.

How do other systems that use mark&sweep allow traversals of potntially circular structures to detect that?


Examine what is said, not who speaks.
Silence betokens consent.
Love the truth but pardon error.

Replies are listed 'Best First'.
Re^3: Circular reference testing.
by hv (Prior) on Mar 10, 2005 at 09:41 UTC

    [numifying a reference to something other than an actual memory address] would tend to invalidate the mechanisms (mostly using hashes), in use by existing modules also?

    It needn't do so: all that is required is that the value be a) consistent and b) unique. If some person or other tries to cheat by making assumptions about the value, then yes their approach could be invalidated by such a change.

    it begs requires the question of whether there will be some mechanism for asking the [Ponie] VM about circular references

    I anticipate that Ponie would throw away the reference count (thus reducing the minimum size of an SV below 12), and maybe introduce another level of indirection (which could reduce the size of all SV headers to 4 or 8), but as long as references continue to numify to a consistent unique value (and probably still the memory address) the existing techniques will continue to work for discovering circular references.

    Hugo

      I guess that means that my bitvector technique will be of short-lived utility, but for now, it is doing sterling service for me.

      That said, even if they manage to reduce the size of SV headers to 8 bytes (they'll still need the flags and type fields won't they?), then that still means that using a bitvector would only require 64 MB to handle a 32-bit/4GB address space and with many OS/32-bit processors, your restricted to 2GB anyway, so 32 MB max.

      That's still way less than Data::Dumper currently uses for a 500 MB HoHoA which would only require < 8MB. Admittedly, D::D does do rather more than just detect self-refs which is all I need.

      That said, the technique is so fast, that it wouldn't be a great burden doing two passes. The first simply sets the bits. The seconds then only need rcord the salient information for the refs that are self refs. The reduction in memory allocations may even achieve a time saving as well.


      Examine what is said, not who speaks.
      Silence betokens consent.
      Love the truth but pardon error.