Constancy of X'Address?

Constancy of X'Address?

[Niklas Holsti]

A discussion in comp.arch (on the new C23 standard for C) brought up 
these questions, which I could not answer with confidence:

- Is the address of an object constant in Ada? That is, if I have some 
object X in an Ada program, do repeated applications of X'Address always 
return the same value?

- Does the answer depend on how X is allocated (created): on the library 
level, on the stack, or in a pool ("new")?

The issue behind this question is whether an Ada program could use 
garbage collection that moves objects around, for example a compacting 
collector.

Re: Constancy of X'Address?

[Maxim Reznik]

If the type of the object is limited, then the object address is a constant. For other objects there is no such guaranty I guess.

Re: Constancy of X'Address?

[Jeffrey R.Carter]

On 2023-04-05 11:24, Niklas Holsti wrote:
> 
> - Is the address of an object constant in Ada? That is, if I have some object X 
> in an Ada program, do repeated applications of X'Address always return the same 
> value?
> 
> - Does the answer depend on how X is allocated (created): on the library level, 
> on the stack, or in a pool ("new")?

'Address is discussed in ARM 13.3 
(http://www.ada-auth.org/standards/aarm12_w_tc1/html/AA-13-3.html). (12.c) says 
"The validity of a given address depends on the run-time model; thus, in order 
to use Address clauses correctly, one needs intimate knowledge of the run-time 
model."

Under Implementation Advice, (15-16) say "The recommended level of support for 
the Address attribute is:

"X'Address should produce a useful result if X is an object that is aliased or 
of a by-reference type, or is an entity whose Address has been specified."

There is nothing specific about whether the value can change.

-- 
Jeff Carter
"We'll make Rock Ridge think it's a chicken
that got caught in a tractor's nuts!"
Blazing Saddles
87

Re: Constancy of X'Address?

[Randy Brukardt]

I agree with the other answers (for the most part). Not much is guarenteed 
about 'Address. But by-reference and aliased objects have to *work* like 
they are not moved. If the runtime can deal with moving such things, Ada 
doesn't care.

As a practical matter, most Ada implementations assume objects don't move. 
Janus/Ada assigns everything at compile-time, so the only time anything 
moves is when it is created or destroyed.

The big problem with garbage collection in Ada is that early finalization is 
not allowed (other than a few tiny exceptions in failure cases and [in 
post-Ada 22] certain function results.) So any object that might have a 
controlled part can never be garbage collected, even if there is no other 
use or access to it.

Changing that is a very hard problem, as you cannot allow finalization to 
happen at any instant or by any arbitrary task (if you did, every 
finalization would be a race scenario, and every Finalize routine would need 
dedicated locking). I've suggesting allowing it for "unreachable objects" 
(not a useful definition by itself, it would need to be defined) at places 
where masters are being exited anyway (so finalization should be expected at 
those locations). But it's unclear if you can build a useful garbage 
collector that way (and what the overhead would be).

                     Randy.



"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:k94t2nFelgbU1@mid.individual.net...
>A discussion in comp.arch (on the new C23 standard for C) brought up these 
>questions, which I could not answer with confidence:
>
> - Is the address of an object constant in Ada? That is, if I have some 
> object X in an Ada program, do repeated applications of X'Address always 
> return the same value?
>
> - Does the answer depend on how X is allocated (created): on the library 
> level, on the stack, or in a pool ("new")?
>
> The issue behind this question is whether an Ada program could use garbage 
> collection that moves objects around, for example a compacting collector.