token / ata: Use upgradeable loader to save copies during CPI

[joncinque]

Problem

When executable accounts are passed into a program for CPI, their entire program data is copied over as well. This can create overhead for programs using the non-upgradeable loader. Programs using the upgradeable loader aren't affected, since only 36 bytes are in the program account.

The token / associated-token-account use the non-upgradeable loader, which makes them susceptible to this issue.

They should use the upgradeable loader (as finalized programs, of course)! The current upgrade method, however, only swaps the program accounts, which would cause an issue for the program data account associated with the program, since that's derived from the program address.

Proposed Solution

During the next upgrade, use the upgradeable loader for the program, and in the runtime, move the program and program data accounts.

[joncinque]

I believe this isn't required because all programs, even ones on the old loader, don't have their bytecode copied in and out of instruction contexts during CPI. @Lichtso can you confirm?

[Lichtso]

The bytecode is not copied during CPI for the program that is being called.
For instruction accounts however the content is copied (even if it is a program).

[joncinque]

Ah I think I see, so if I have:

my program -> some other program -> Token program

When my program CPIs into some other program and provides the token program as an instruction account, then the bytecode for token program is copied into some other program, correct? If so, would there be a benefit to moving the token program to the upgradeable loader?

[Lichtso]

When my program CPIs into some other program and provides the token program as an instruction account, then the bytecode for token program is copied into some other program, correct?

Correct.

If so, would there be a benefit to moving the token program to the upgradeable loader?

All loaders behave the same in terms of what they copy, so no benefit there.
The account data direct mapping feature however will solve this across all loaders.

[joncinque]

Ah ok, sounds like this is very closable then, thanks!