[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Liberty-eiffel] Happy new year

From: Raphael Mack
Subject: Re: [Liberty-eiffel] Happy new year
Date: Thu, 22 Jan 2015 21:53:15 +0000
User-agent: Horde Application Framework 5


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

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

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]