Re: [Liberty-eiffel] Happy new year

[Raphael Mack]

Hi,

Zitat von Cyril ADRIAN <address@hidden>:
> 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...

This was my first impression, too. But when you take a look at where  
bdw_generation is updated, it seems, as bdw_na_markT* might be called  
multiple time for the same native array during one mark phase -> and  
there it might be a nice optimization.

> > 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.

documented is one point, but even more important would be in my eyes  
to detect it (e. g. by stricter checking, or some form of annotation  
in the "generation" feature of the std lib classes. And even better if  
we somehow could do this handling of generation automatically. I. e.  
introduce some notion, to define a feature which is to be called on  
every non-pure (may be qualified) call (here next_generation).

And what happens in case the collection already was modified (e. g. a  
new element added) and the BDW GC gets active before generation is  
increased?

And why capacity is used in a comparable way is still unclear for me...

But maybe we have to remove both the generation and capacity usage  
from the GC...


> 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)

> > - 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?

ok, I believe that it's alive, if I do not mess up the core lib ;-)

> > - 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).

so if there is a feature capacity and multiple native arrays, all  
arrays shall have the same amount of used entries? (or capacity must  
be the maximum and the others explicitly clearing their unused  
elements...

thanks,
Rapha