Re: [Liberty-eiffel] Happy new year

[Cyril ADRIAN]

Hi Raphael,

2015-01-20 22:10 GMT+01:00 Raphael Mack <address@hidden>:

- BDW_GC_DEFINE2.mark_native_arrays checks, whether the current live_type has a feature "generation", I guess to optimize the case, that native arrays are only marked once during a mark phase? But isn't "generation" too generic here?

"generation" is used by the core collections to know when a collection has changed. When that happens, the "old" iterators become invalid.

For BDW, I use the same flag to known if the collection has changed. I have no time to think right now, but just reading the code I am not sure it is such a good idea. Not marking the items of a collection if it did not change seems weird...

 

What if such a featurename exists, but it doesn't have the meaning as in the ITERATORs?

Then you are dealing with a non-standard collection. As for `capacity', it is not actually expected.

I know: those things should be documented. I do agree.

 

And even worse, what if the feature is not in the set of live_features? -> see test/language/test_agent1.e. I think we need to check not only the availability of a feature named "generation", but additionally test whether it is not optimized away. And what, if the generation feature is renamed?

If `generation' is optimized away, then there is a bug somewhere. AFAIR all the core collections do increment `generation' at creation.

If the feature is renamed, it will not be found. Note that the feature does not exist in HOARD, otherwise we could have found it by following the renamings.

But the bottom line is, why the h* did I use that feature in the first place for BDW? (I don't remember)

 

At the end, I think we should check more of the feature, maybe we should even introduce a general concept to call a feature on object modification (to somehow automate the "next_generation" calls in the COLLECTIONS for the iterators)
mhhhhh. I messed up my ABSTRACT_HASHED_DICTIONARY before finding this non-issue... But maybe you can anyhow comment on my questions/ideas.

just did ;-)

 

- I'd like to add the check whether the generation feature is live. Can you tell me how I can a LIVE_TYPE for liveness of a specific feature?

See the LIVE_TYPE.live_features dictionary and the `collected' feature. Your need a FEATURE_STAMP, that you can find in TYPE.lookup. You then need a FEATURE_NAME, you can create it using GLOBAL.as_generation (but try not to build too many objects because the compiler is memory-conservative, -no_gc). You can take inspiration from the way feature names are created for (for instance) `as_capacity' :-)

- BDW_GC_DEFINE2.mark_native_arrays doesn't use its parameter. Is this intended and good?

I'm not sure. It may be either the remains of a previous refactoring or some provisional work. Either way, I just don't remember.

 

- Is it true, that any class can contain at most one native array?

I don't think so. If I remember correctly, it can contain as many native arrays as it likes; but some native features use the `capacity' attribute to know their size (for example: the GC, deep_twin, deep_equal, introspection).

To summarize: if a class uses one or more native arrays:

• it should (must?) also provide a `capacity' attribute. In that case, native arrays must have the same capacity but are automatically handled by native features. Otherwise, the code must redefine deep_twin and deep_equal and not use the GC. I don't know how introspection would work, too.
  
• if may also provide a `generation' attribute. That generation is mostly used by iterators, and I don't understand/remember why BDW should use it too.
  

Cheers,

Cyril