Memory Management in the Cafe SDK

To help your RPX load faster and the linker to run your code faster, the following two workarounds should be implemented. The goal for both workarounds is to export only the symbols that need to be exported.

  1. Re-evaluate the number of modules (RPLs) that you need. The following are good reasons to put code into an RPL:
    • To prevent multiple copies of code.
    • If a module is needed by most or all games, such as coredyn.rpl, gx2.rpl and other system or middleware RPLs.
    • The game RPL has all of the code and data for a game level. A "level" RPL creates no dependencies (is not imported) in the RPX and is not loaded with the RPX. Because a "level" RPL is not loaded with the RPX, the RPX can "release" the RPL to make room for another level. (Cross referencing, where two RPLs import symbols from each other, also creates dependencies.)

    Suggestions:

    • If a module is not a system or middleware RPL, look for situations where an RPL is imported into only a couple of RPLs. For example, do you have an RPL that is only imported into the RPX? If so, put all of the RPL code in the RPX.
    • Another example: consider hypothetical RPLs a.rpl, b.rpl, and c.rpl. If only a.rpl and b.rpl import c.rpl, we suggest moving the code for a.rpl, b.rpl, and c.rpl into only one RPL. (If separate development teams currently make the RPLs, have them make static libs instead.)
    • Put all code that the game RPX has dependencies on (and impossible to unload) in the RPX, except for middleware and system RPLs.
    • If two RPLs cross-reference each other, consider merging them into one RPL. Though cross-referenced RPLs are never unloaded, a merged one might be.
  2. After reducing the number of RPLs, reduce the number of exported symbols to what you need. If you used an "export all" script, such as rplexportall, to create a .def file, the result of that output can be used as a place to start. Most of the symbols produced by the script are not good entry points into the RPL. The fewer symbols that you have, the faster they load. But, more importantly, you can avoid an out of memory error.

    Suggestion:

    Import a RPL that needs its exports reduced into the RPX. For clarity, the .def file created by rplexportall is referred to as the "old" .def file as opposed to the "new" .def file, which contains only the symbols that you need:

    1. After you use rplexportall to create a temporary "old" .def file for the RPL, remove the "old" .def file from the makefile for the RPL. That is, preprpl[32|64] is called without the -x option (the -x option uses the .def file as a parameter), which results in nothing being exported from the RPL.
    2. Link the RPL and call makerpl[32|64] as you normally do.
    3. Link the RPX with all applicable import libraries, including the import library you made for your RPL with either preprpl[32|64] or makerpl[32|64], depending on your options.
    4. The link should generate some link errors for undefined symbols. Capture the errors from the linker so that you can put the symbol names into the clipboard.
    5. If your game uses C++, some of the symbol names will be mangled, that is, the name will contain the function name and references to classes and arguments. If the name is mangled, it can be confusing. However, rplexportall prints a normal looking function name in a comment (an unmangled name) on the same line as the mangled name to help you to understand which symbols are being exported.
    6. Copy each unique symbol name in the list of undefined symbol names to the clipboard, and then search for the name in the "old" .def file. When you find it, copy the entire line with the mangled and unmangled names, and then paste it in the "new" .def file. After you find all of the unique, undefined symbols, the "new" .def file should contain only the symbols that are needed. If you use preprpl[32|64] to create your import library, you need to also copy [CODE] and [DATA], and then put those directives above function names and variable names in your "new" .def file. You may have multiple instances of these directives in your "new" .def file.
    7. Finally, call the "new" .def file using preprpl[32|64] with the -x option, and then repeat the steps b and c. If you still have link errors, repeat steps d through g until you link the RPX successfully.

Revision History

2013/05/08 Automated cleanup pass.
2012/07/23 Removed references to old SDKs.
2011/12/19 Initial version.


CONFIDENTIAL