On 2009-10-19 18:19:34 +0200, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> said:
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
Leandro Lucarella wrote:
Andrei Alexandrescu, el 19 de octubre a las 08:38 me escribiste:
For relatively large chunks of memory, the GC keeps a control block.
We could add a member size_t requestedSize that keeps the size that
was requested with an allocation/reallocation call. The GC can take
initiative in overallocating memory and expose primitives such as
requestedSize (how much did the program ask for?) and capacity (how
much is really allocated?). With that API, it is possible to
implement ~= efficiently.
That would mean moving the overhead of arrays to the GC, but that overhead
will be present for *all* objects, arrays or not, so I don't think it will
be a good idea...
I forgot to mention that ~= would also have a means to communicate the
GC to overallocate. My point is simple: the problem is that slices don't
store enough info. That info could get in the memory control block.
This is the part of this thread I'm not understanding: Isn't this info stored
already? The only problem is querying it is slow. See GC.sizeOf(),
and bug 2900.
(2900 is fixed, but it's still slow, and there's still bug 2093.)
What are you
proposing that's different from the status quo?
Sorry, I got confused a bit: you have the size in the array and you can
get the capacity from the GC, just slowly. Let's sleep on this some
more, it may not be impossible to find a growth scheme that works fast.
Andrei
The problem with the current state, apart slow access to the capacity,
is an ownership problem: which of the possibly multiple slices owns the
data after the slice? what happens when multiple slices grow?
In some way the current state is the optimal solution with slice=array.
To improve on this the only way is (I think) to have slice!=array, and
this was basically what T[new] was all about (at least in my
understanding).
Ownership of data is a difficult problem with arrays, and clearly
T[new] and slices is more complex than having slice=array, I would be
tempted to say that on the whole having T[new] (or even a library
vector type, if T[new] does not improve upon what a library type does),
might be a good idea.
Fawzi
