|
|
- #####################################################################
- # CS:APP Malloc Lab
- # Traces
- #
- # Copyright (c) 2002, R. Bryant and D. O'Hallaron, All rights reserved.
- # May not be used, modified, or copied without permission.
- #
- ######################################################################
-
- This directory contains traces of allocate and free requests that are
- used by the test harness to evaluate the student malloc packages.
-
- *********
- 1. Files
- *********
-
- *.rep Original traces
- *-bal.rep Balanced versions of the original traces
- gen_XXX.pl Perl script that generates *.rep
- checktrace.pl Checks trace for consistency and outputs a balanced version
- Makefile Generates traces
-
- Note: A "balanced" trace has a matching free request for each allocate
- request.
-
- **********************
- 2. Building the traces
- **********************
- To rebuild the traces from scratch, type
-
- unix> make
-
- ********************
- 3. Trace file format
- ********************
-
- A trace file is an ASCII file. It begins with a 4-line header:
-
- <sugg_heapsize> /* suggested heap size (unused) */
- <num_ids> /* number of request id's */
- <num_ops> /* number of requests (operations) */
- <weight> /* weight for this trace (unused) */
-
- The header is followed by num_ops text lines. Each line denotes either
- an allocate [a], reallocate [r], or free [f] request. The <alloc_id>
- is an integer that uniquely identifies an allocate or reallocate
- request.
-
- a <id> <bytes> /* ptr_<id> = malloc(<bytes>) */
- r <id> <bytes> /* realloc(ptr_<id>, <bytes>) */
- f <id> /* free(ptr_<id>) */
-
- For example, the following trace file:
-
- <beginning of file>
- 20000
- 3
- 8
- 1
- a 0 512
- a 1 128
- r 0 640
- a 2 128
- f 1
- r 0 768
- f 0
- f 2
- <end of file>
-
- is balanced. It has a recommended heap size of 20000 bytes (ignored),
- three distinct request ids (0, 1, and 2), eight different requests
- (one per line), and a weight of 1 (ignored).
-
- ************************
- 4. Description of traces
- ************************
-
- * short{1,2}-bal.rep
-
- Tiny synthetic tracefiles for debugging
-
- * {amptjp,cccp,cp-decl,expr}-bal.rep
-
- Traces generated from real programs.
-
- * {binary,binary2}-bal.rep
-
- The allocation pattern is to alternatively allocate a small-sized
- chunk of memory and a large-sized chunk. The small-sized chunks
- (either 16 or 64 ) are deliberately set to be power of 2 while the
- large-size chunks (either 112 or 448) are not a power of 2. Defeats
- buddy algorithms. However, a simple-minded algorithm might prevail in
- this scenario because a first-fit scheme will be good enough.
-
- * coalescing-bal.rep
-
- Repeatedly allocate two equal-sized chunks (4095 in size) and release
- them, and then immediately allocate and free a chunk twice as big
- (8190). This tests if the students' algorithm ever really releases
- memory and does coalescing. The size is chosen to give advantage to
- tree-based or segrated fits algorithms where there is no header or
- footer overhead.
-
- * {random,random2}-bal.rep
-
- Random allocate and free requesets that simply test the correctness
- and robustness of the algorithm.
-
-
- * {realloc,realloc2}-bal.rep
-
- Reallocate previously allocated blocks interleaved by other allocation
- request. The purpose is to test whether a certain amount of internal
- fragments are allocated or not. Naive realloc implementations that
- always realloc a brand new block will suffer.
-
|