Re: Ada GC (was Re: Ammo-zilla)

["Vladimir Olensky" <vladimir_olensky@yahoo.com>]

Robert Dewar wrote in message <7vvroo$grr$1@nnrp1.deja.com>...
>In article <s23mnbp024223@corp.supernews.com>,
>  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
>>
>> Robert Dewar wrote in message <7vqd45$iiq$1@nnrp1.deja.com>...
>> >In article <s20tckqd24291@corp.supernews.com>,
>> >  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
>> >> As for me I fully support that.
>> >> I think that any unchecked conversions should
>> >> be disallowed for pointers that are traced by GC.
>> >> It is not only extremely unsafe but I do not see any sense
>> >> in that if language is extended to support GC.
>> >
>> >But that of course is not enough to prevent scary GC bugs :-)
>>
>> Yes, I agree this does not prevent  GC bugs that may exist
>> in GC implementation itself.  But at least that could  provide
>> isolation between GC implementation and GC client.
>> The last one will never be able to spoil anything in GC
>> internal data.
>
>Again you miss my point, unless you segregate memory with
>hardware memory protect, allowing unchecked conversion, and
>hence address calculations, anywhere, can damage data structures
>anywhere. I am NOT talking about bugs in the GC implementation
>itself.


I see your point now.

Of course it is very dangerous to perform any calculations (e.g address
arithmetic) for something that is hidden behind protection wall and one
does not know for sure what is there in reality.
This is especially dangerous when different kinds of memory pools are
mixed and one does not know for sure on which kind of memory one
is trying to perform such operations.

It just never come to my mind that someone (one the client's side)
could try to do something (using unchecked conversions ) for anything
that is behind that protection wall  (for me it is a crazy idea).

Mapping between external world and internal world relative to that wall
could
only be allowed to the subsystem responsible for that protection wall.

As a matter of fact  I do not see the way how one can penetrate in reality
through hardware memory protection wall directly using pointer arithmetic.
One need to have access to some system resources to do that. But if one
could perform such operations with the virtual addresses on this side of the
wall and if one does not know how they map to the real physical addresses
it could cause problems.

On the other hand you already pointed out the way to reduce that danger:
".. unless you segregate memory with hardware memory protect ..".

Here I could also add that I think that it is not too dangerous  to perform
address arithmetic within single allocated chunck of memory providing that
measures have been taken to ensure that the result is within memory
boundaries
of the allocated memory chunck.  Reading/Writing data using such resulting
address
could be dangerous of course.

It could be extremely dangerous to use address arithmetic trying to
calculate location
of the prev/next memory chunk or object in the memory if allocated memory
chunks
are not contiguous that could be the case when  using hardware protected
memory.

In the best case one will get GPF, in the worst case one may damage data
structures.

With some overhead some measures could be taken to check pointer validity
to increase safety. This could be  keeping (hashed) table/list of pointers
to allocated
objects  and use that table/list to check pointer validity . Here I should
mention  very
interesting example in GNAT distribution, namely  System.Debug_Pool package
that
makes use of  H-table to keep the status of each storage chunk used in that
pool.

Generally there could be many approaches to increase safety.
One of the nice ones (for me)  is to use notion of safe and unsafe
modules/packages as in Modula-3 and do not allow any unsafe
operations in safe packages.

Regards,
Vladimir Olensky