Re: [Liberty-eiffel] GC

[Cyril ADRIAN]

Hi Raphael,

Sorry for the delay but as you can see I don't have a lot of time for Liberty those days :-(

2014-10-23 23:06 GMT+02:00 Raphael Mack <address@hidden>:

Cyril do you have a glue what the parameter string_at_run_time in MEMORY_HANDLER.manifest_string_in is good for? I see only ONE call of this feature, whith the constant True.

Indeed. Looking at the "if" a few lines above I think it is the remnant of some refactoring.

Similar for MEMORY_HANDLER.native9_in:
* I dislike the name

Yes. 9 is the hard-coded id of NATIVE_ARRAY[CHARACTER]

* I don't see any call of it

Neither do I... Dead code? Just remove it :-)

* the implementation of this deferred feature in SEGC and BDW is quite different (call of se_malloc in the opposite branch)

You are right, GC_HANDLER's is wrong. Anyway I agree it can be removed.

Can you enlighten me here?

It smells like rotting remnants of some past refactoring. You don't need my permission to refactor ;-)

And could you describe the special handlings for NATIVE_ARRAYs with respect to garbage collection? - I don't understand the idea behind LIVE_TYPE_NATIVE_ARRAY_COLLECTOR.

The idea is that when an object is removed from a collection its pointer is not overridden with NULL. For efficiency reasons, if the GC is not compiled in (using -no_gc) there should be no performance penalty because of the extra write.

But when the GC runs it must not mark those pointers as alive; hence the special feature `mark_native_arrays` that marks each item using the `mark_item` built-in that the containing collection thinks really is reachable.

Both features are defined in NATIVE_ARRAY_COLLECTOR.

See the comments in NATIVE_ARRAY_COLLECTOR, and e.g. FAST_ARRAY.mark_native_arrays.

Cheers,

Cyril