renames and access

renames and access

[Francesco Bochicchio]

Hi all,

I have a piece of code that does something like this:

type REC_T is record
	A : Integer;
	B : String(4)
end record;

type REC_PTR_T is access REC_T;
REC_PTR : REC_PTR_T := new REC_T;

A renames REC_PTR.A;
B renames REC_PTR.B;

At this point, I can use A and B as if they where simple 
variables. BUT, when I later reallocate the memory like this:

function REALLOCATE_MEMORY return REC_PTR_T;
REC_PTR := REALLOCATE_MEMORY(); -- Actually, the ability to reallocate is
                                -- the reason for all this  fuss.
				--

then A and B still points to the old memory, not at the one currently
pointed by REC_PTR.

Is this normal ??(I work with ObjectADA, did not try yet with GNAT)  
Is there any way to have the renames to automatically points to the new
memory?
If this turns impossible, what would be an equivalent solution? At the
moment, my bet is to turn the renames into access. Any better idea?

BACKGROUND : the reason for all this is that we are trying to add a
failover capability to a very old application of many thousand lines 
of code. Therefore, the 'critical variables' (one hundred or more) shall
be allocated in a special area of memory which is mirrored between the
primary machine and its backup, where  a copy of the application
runs in hot standby. The trick with the renames should have spared us from
changing every line of code referring to one of these variables.

Thanks for any hints you can give me.

Ciao
-----
FB  

Re: renames and access

[Randy Brukardt]

"Francesco Bochicchio" <bockman@virgilio.it> wrote in message
news:pan.2004.02.11.19.14.49.293492@virgilio.it...

> Is this normal ??(I work with ObjectADA, did not try yet with GNAT)

Yes. When you call "Reallocate_Memory", you're getting a new object, and
assigning an access to that into Rec_Ptr. But a renames provides a new name
for an object, in this case the original object that you renamed.

> Is there any way to have the renames to automatically points to the new
> memory?

I can't think of one. You could rename the access object, but that hardly
helps.

> If this turns impossible, what would be an equivalent solution? At the
> moment, my bet is to turn the renames into access. Any better idea?

I don't have one, but perhaps someone else will.

             Randy.

Re: renames and access

[Robert A Duff]

"Francesco Bochicchio" <bockman@virgilio.it> writes:

> Hi all,
> 
> I have a piece of code that does something like this:
> 
> type REC_T is record
> 	A : Integer;
> 	B : String(4)
> end record;
> 
> type REC_PTR_T is access REC_T;
> REC_PTR : REC_PTR_T := new REC_T;
> 
> A renames REC_PTR.A;
> B renames REC_PTR.B;
> 
> At this point, I can use A and B as if they where simple 
> variables. BUT, when I later reallocate the memory like this:
> 
> function REALLOCATE_MEMORY return REC_PTR_T;
> REC_PTR := REALLOCATE_MEMORY(); -- Actually, the ability to reallocate is
>                                 -- the reason for all this  fuss.
> 				--
> 
> then A and B still points to the old memory, not at the one currently
> pointed by REC_PTR.
> 
> Is this normal ??

Yes.  You've renamed an object that no longer exists.

>...(I work with ObjectADA, did not try yet with GNAT)  

Don't bother -- GNAT will do the same.

> Is there any way to have the renames to automatically points to the new
> memory?

No.

> If this turns impossible, what would be an equivalent solution? At the
> moment, my bet is to turn the renames into access. Any better idea?

Turning into access would work, but then you have to modify all the
clients.  But how about this:

    function A return Integer is
    begin
        return REC_PTR.A;
    end A;

?

> BACKGROUND : the reason for all this is that we are trying to add a
> failover capability to a very old application of many thousand lines 
> of code. Therefore, the 'critical variables' (one hundred or more) shall
> be allocated in a special area of memory which is mirrored between the
> primary machine and its backup, where  a copy of the application
> runs in hot standby. The trick with the renames should have spared us from
> changing every line of code referring to one of these variables.
> 
> Thanks for any hints you can give me.

I recently had a similar experience.  We decided that a certain
abstraction should be changed, because of efficiency reasons.
We couldn't just change the private part and package body;
we had to change the *interface*.  And that implied modifying 
approx 1000 lines of code in the clients.  So I searhed for everywhere
it was used, and fixed all the uses.  This required studying the
procedures called by the uses in many cases -- a big job that took
a long time.  But when I was done, after fixing some problems where the
compiler complained, all regression tests passed, first try!
No debugging.

- Bob

Re: renames and access

[Stephen Leake]

"Francesco Bochicchio" <bockman@virgilio.it> writes:

> Hi all,
> 
> I have a piece of code that does something like this:
> 
> type REC_T is record
> 	A : Integer;
> 	B : String(4)
> end record;
> 
> type REC_PTR_T is access REC_T;
> REC_PTR : REC_PTR_T := new REC_T;
> 
> A renames REC_PTR.A;
> B renames REC_PTR.B;
> 
> At this point, I can use A and B as if they where simple 
> variables. BUT, when I later reallocate the memory like this:
> 
> function REALLOCATE_MEMORY return REC_PTR_T;
> REC_PTR := REALLOCATE_MEMORY(); -- Actually, the ability to reallocate is
>                                 -- the reason for all this  fuss.
> 				--
> 
> then A and B still points to the old memory, not at the one currently
> pointed by REC_PTR.
> 
> Is this normal ??

Yes. The result of the rename statements is cached.

> Is there any way
> to have the renames to automatically points to the new memory? 

You have to evaluate them again after you change Rec_Ptr:

loop
  rec_ptr := Reallocate_Memory;
  declare
     a : Integer renames REc_ptr.a;
     b : string (4) renames REc_Ptr.b;
  begin
     ...
  end;
end loop

> If this turns impossible, what would be an equivalent solution? 

I need to see more context to suggest other ways of proceeding. Do you
have a loop like I wrote above?

> BACKGROUND : the reason for all this is that we are trying to add a
> failover capability to a very old application of many thousand lines 
> of code. Therefore, the 'critical variables' (one hundred or more) shall
> be allocated in a special area of memory which is mirrored between the
> primary machine and its backup, where  a copy of the application
> runs in hot standby. The trick with the renames should have spared us from
> changing every line of code referring to one of these variables.

Change the variables into equivalently named functions, whose bodies
reference the pointer. 

-- 
-- Stephe

Re: renames and access

[Francesco Bochicchio]

On Wed, 11 Feb 2004 21:32:02 +0000, Stephen Leake wrote:

> "Francesco Bochicchio" <bockman@virgilio.it> writes:
> 
>> Hi all,
>> 
>> I have a piece of code that does something like this:
>> 
>> type REC_T is record
>> 	A : Integer;
>> 	B : String(4)
>> end record;
>> 
>> type REC_PTR_T is access REC_T;
>> REC_PTR : REC_PTR_T := new REC_T;
>> 
>> A renames REC_PTR.A;
>> B renames REC_PTR.B;
>> 
>> At this point, I can use A and B as if they where simple variables.
>> BUT, when I later reallocate the memory like this:
>> 
>> function REALLOCATE_MEMORY return REC_PTR_T; REC_PTR :=
>> REALLOCATE_MEMORY(); -- Actually, the ability to reallocate is
>>                                 -- the reason for all this  fuss.
>> 				--
>> 
>> then A and B still points to the old memory, not at the one currently
>> pointed by REC_PTR.
>> 
>> Is this normal ??
> 
> Yes. The result of the rename statements is cached.
> 
>> Is there any way
>> to have the renames to automatically points to the new memory?
> 
> You have to evaluate them again after you change Rec_Ptr:
> 
> loop
>   rec_ptr := Reallocate_Memory;
>   declare
>      a : Integer renames REc_ptr.a;
>      b : string (4) renames REc_Ptr.b;
>   begin
>      ...
>   end;
> end loop
> 

This was a nice idea, but not enough. I tried that: only the code in the
declare block see the new renames. Code in functions defined before the
declare block continues to see the old renames, also if the function  is
called inside the declare block. Same goes for other packages or other
tasks (as I said, it is very old code, badly written, and the use of
global variables is pervasive).


>> BACKGROUND : the reason for all this is that we are trying to add a
>> failover capability to a very old application of many thousand lines of
>> code. Therefore, the 'critical variables' (one hundred or more) shall
>> be allocated in a special area of memory which is mirrored between the
>> primary machine and its backup, where  a copy of the application runs
>> in hot standby. The trick with the renames should have spared us from
>> changing every line of code referring to one of these variables.
> 
> Change the variables into equivalently named functions, whose bodies
> reference the pointer.

I though of that, but this is real-time software and I would prefer not to
add an extra function call every time one of these variables (which
happens very often in the processing loop ). We already have performance
concerns with the code as it is.

Also, if I use function returning pointers, like this:

type INTEGER_P is access all INTEGER; function A returns INGEGER_P is
begin
	return REC_PTR.A'access;
end A;

then I still have to change code like this:
    A := 3;
into:
    A.all := 3.
which is the same effort that writing:
    REC_PTR.A := 3;
which is what I'm trying to avoid, since I would have to search and modify
all critical variable usage in about 40000 lines of code (but I'm starting
to think that there is no way to avoid it).


Thanks anyway, also to the others that answered.

Ciao
-----
FB

Re: renames and access

[Francesco Bochicchio]

On Wed, 11 Feb 2004 19:02:23 +0000, Robert A Duff wrote:

> 
>> If this turns impossible, what would be an equivalent solution? At the
>> moment, my bet is to turn the renames into access. Any better idea?
> 
> Turning into access would work, but then you have to modify all the
> clients.

Right.

>  But how about this:
> 
>     function A return Integer is
>     begin
>         return REC_PTR.A;
>     end A;
> 
> ?
>

I thought of that:

1. It adds a function call overhead for each time one of the variables is
   accessed ( and it happens a lot )
2. It only solves variable reading. I don't see any equivalent way to
assign values to the variables.


Thanks anyway.

Ciao
-----
FB

Re: renames and access

[Martin Dowie]

"Francesco Bochicchio" <bockman@virgilio.it> wrote in message > I thought of that:
> 
> 1. It adds a function call overhead for each time one of the variables is
>    accessed ( and it happens a lot )

What sort of processor are you using and what sort of timing
constraints do you have? You may find that the time taken to perform
the function call (even a lot of them) isn't as much as you would
think. This is especially true if porting from, for example, a 68020
to a PPC740.

In some cases, including function/procedure calls, instead of inlining
the equivilant code and speed you app up (by avoid cache misses).

Re: renames and access

[Georg Bauhaus]

Francesco Bochicchio <bockman@virgilio.it> wrote:
: I though of that, but this is real-time software and I would prefer not to
: add an extra function call every time one of these variables (which
: happens very often in the processing loop ). We already have performance
: concerns with the code as it is.

Have you tried pramga Inline?

Re: renames and access

[Robert I. Eachus]

Francesco Bochicchio wrote:

> I thought of that:
> 
> 1. It adds a function call overhead for each time one of the variables is
>    accessed ( and it happens a lot )

It does NOT add function call overhead, especially if you in-line the 
function.  What it does do is insist that the names be re-evaluated when 
used.  To the extent that this is what you wish, you get what you asked 
for.  If you can use a grosser level of granularity, you can put some 
sections of code in a handler that just reinvokes the code, and have the 
code use local renames.

> 2. It only solves variable reading. I don't see any equivalent way to
> assign values to the variables.

Huh?  A function that returns an access type can appear as part of a 
name on the left hand side of an assignment statement.  So if you have a 
function A that returns a pointer to an object with components C,D and E 
of type Integer,

A.E := 3;

works just fine.

What you might have to do is a global replace on the code to change 
current instances of E to A.E assuming A and B are record containing the 
data that you want replicated.  Notice that a renaming of A.E as E will 
"lock in" the current dereference.  You can combine it with what I said 
above about granularity, and if the retries occur at a high enough level 
you won't have to change much.  (All you have to do is put all renames 
inside the code that is retried after a failure.)

There is no easy way to do the analysis needed to decide how far out you 
can move the retries in various areas of the code.  But once you do 
that, renamings should work fine.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush