chapter 3.5 memory and i/o systems. 2 memory management memory problems are one of the leading...
TRANSCRIPT
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