[M3devel] REFANY-keyed tables?

[Rodney M. Bates]

On 02/26/2014 10:01 PM, JC Chu wrote:
>> Hmm, can you point out where these are?
>
> See for example <https://modula3.elegosoft.com/cm3/doc/help/interfaces.html#table>.
>
>> I have some pointer-keyed tables, but they use techniques like giving every object an object sequence number field, explicitly initialized when an object is allocated, and using that for the Hash function.  But this won't work for REFANY, because it can have no fields.
>
> The keys are indeed objects that require explicit initialization.  Thanks for the suggestion.
>
>> The garbage collector is a (partially) compacting collector, which means it can move a heap object and adjust all the pointers to it, if it knows where they all are, which holds for some objects.  So the bit contents of a REFANY can change.
>
> Just out of curiosity, is there any way to lock the GC temporarily?

Look in cm3/m3-libs/m3core/src/runtime/common/RTCollector.i3.  There are various
procedures you can call at runtime to [dis|en]able different collection strategies
or stop collection altogether, with performance consequences, obviously.  For example,
DisableMotion will prevent moving any heap objects.  If you did this, you
really could use a REFANY directly as a hash code in a Ref*Tbl.  You would
still have to provide a different Hash function that actually did this, instead
of just excepting.

(Can "except" be verbed?  Some say any word can be verbed.)

>
> — JC Chu
>
> -----Original Message-----
> From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop]
> Sent: Thursday, February 27, 2014 11:28
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] REFANY-keyed tables?
>
>
>
> On 02/26/2014 11:08 AM, JC Chu wrote:
>> Hi,
>>
>> I need a REFANY-to-INTEGER table in my program but RefIntTbl.Default is giving me runtime errors.  Apparently Table(Key, Value) uses Key.Equal() and Key.Hash(), but those procedures in Refany, which is use to instantiate RefIntTbl, both raise a fatal exception.
>>
>
> The garbage collector is a (partially) compacting collector, which means it can move a heap object and adjust all the pointers to it, if it knows where they all are, which holds for some objects.  So the bit contents of a REFANY can change. This means it is not possible to have a consistent Hash on the pointer value alone.
>
> So Refany.Hash is deliberately coded to raise this exception, to prevent a far more insidious bug.
>
>> I’m a bit confused since a number of REFANY-keyed tables are shipped with CM3.  Is this actually the expected behavior or am I doing anything wrong?
>>
>
> Hmm, can you point out where these are?
>
> I have some pointer-keyed tables, but they use techniques like giving every object an object sequence number field, explicitly initialized when an object is allocated, and using that for the Hash function.  But this won't work for REFANY, because it can have no fields.
>
> So the table can only work on a narrower set of allocated object types than REFANY.
> If you need the table to hold addresses of a mixture of different types, you can still do that with a hierarchy of OBJECT types, but they will have to have a common supertype that contains whatever fields the Hash function needs for consistency.
>
> It would be possible that pointers get passed around in REFANY-typed (statically) variables, but it is carefully arranged that they all have an allocated type that has fields a Hash function can work on.  Hash would then have to do a NARROW or TYPECASE to the type it expected.
>
> Rodney Bates
>
>> Thanks.
>>
>> — JC Chu
>>
>
>