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.