Chapter 3.5Memory and I/O Systems

2

Memory Management

Memory problems are one of the leading causes of bugs in programs (60-80%)

MUCH worse in languages with explicit memory management (C or C++)

In garbage collecting languages (e.g. Java, Python, Unicon) you may still have leaks due to OS, memory reference cycles, or live-but-never used data

3

Memory Management

We have three goals when working with memory Safety Knowledge Control

4

Memory Management

Memory fragmentation Free physical memory is only available

in chunks Can prevent an allocation from

completing successfully even if there's plenty of free memory

Virtual addressing helps with fragmentation problems

5

Memory Management

Virtual addressingVir tu a l

Ad d r es s T ab le

Blo c k 2

Blo c k 4

Blo c k 3

Blo c k 5

Blo c k 1

P h y s ic a l M em o r y

Blo c k 1

Blo c k 4

Vir tu a lM em o r y View

6

Memory Management

“Static” memory allocation Really means: globals + stack If all memory is statically allocated

there will be very few problems. Mostly rules out:

Leaks Fragmentation Running out of memory

Very restrictive Lots of underutilized memory Many old games were done this way

7

Memory Management

“Dynamic” allocation Really, this is talking about heap

allocation Much more flexible than static

allocations Lots of potential problems Often: override global new and delete

to control allocations

8

Memory Management

Memory manager Heaps are large collections of memory

allocated for arbitrary mixed uses Managed by language runtime system Especially in C/C++: simple error-

checking schemes reduce memory overrun problems

Slow and wasteful of memory for lots of small objects

9

Memory Management

Memory leaks A memory leak is a memory allocation

that is no longer necessary and was not released by the program

Memory leaks can cause the game to use up resources and run out of memory

To find memory leaks, look for all the allocations that occurred between two particular points in time

10

Memory Management

Memory pools Memory pools are contiguous blocks of

memory used to allocate objects Allocations are extremely fast There is no fragmentation... Except for all the unused space We can allocate objects from specific

classes with a simple macro

11

Memory Management

Memory pools

E m p ty b lo c kE m p ty b lo c k h ead erBlo c k w ith d a ta

a b c

12

File I/O

Full file I/O (e.g. reading/writing local named files) not always available

Many different API’s and speeds of accessing different devices Memory cards, network, etc

Game developer usually has no control over physical disk allocation Which can lead to long load times

13

File I/O

Unified file system Platform independent Provide same interface to different

types of media Based around FileSystem class

14

File I/O

File system Uses concept of streams Stream can be the source of data Possible sources

File, memory, network Or it can be a layer that adds some

properties Possible layers

Buffering, compression, range, etc

15

File I/O

File system

B uffe r ingL aye rF ile So urc e

D ataS tre am

16

Game Resources

A game resource (or asset) is anything that gets loaded that could be shared by several parts of the game A texture, an animation, a sound, etc

We want to load and share resources easily

There will be many different types of resources in a game

17

Game Resources

Resource manager Uses registering object factory pattern Can register different types of

resources All resource creation goes through the

resource manager Requests for existing resources usually

don't have to load it again Basically a giant in-memory cache

18

Game Resources

Resources and instances Resource is the part of the asset that

can be shared among all parts of the game

Instance is the unique data that each part of the game needs to keep on its own

This is exactly the flywheel design pattern

19

Game Resources

Resource lifetime How do we know when we can destroy

shared resources? All at once At the end of the level

Explicit lifetime management Reference counting, garbage collection GPU resources may be managed

differently than CPU resources

20

Serialization

Every game needs to save and restore some game state Even for check point saves

Level editing and creation could be implemented as a saved game

21

Serialization

Saving [I]Serializable interface for read and

write operations Each class implements a Write()

(or writeObject(), etc) function Saving pointers is a problem

They won't be the same when we load So save an ID of some kind

Saving open OS handles is also no good

22

Serialization

Loading Create object types through an object

factory Read() function takes care of loading the

data from the stream, assigning IDs stored in file with newly created objects/pointers

Pointers are loaded into a translation table Second pass fixes up all the pointers