COMP 412, Fall 2024 Lab 2: Local Register Allocation Table of Contents
Critical Dates for the Project
- IntroductionCode Due Date 10/23/2024
- Overview of the ProblemCode Check #1 Due 10/04/2024
- Code Specification3
- Introduction
In this programming assignment you will build a local register allocator—that is, a program thatreads in a single block of ILOC code, transforms that block so that it uses a specified number ofregisters, and writes the transformed block out to the standard output stream. The input andoutput blocks are both written in the ILOC subset used in Lab 1. Section A.1 of this documentdescribes the ILOC subset and its simulator.For the purposes of this lab, an input program and an output program are considered equivalent if and only if they print the same values in the same order to stdout and each data-memory location defined by an execution of the input program receives the ame value when the output program executes. The output program may define additional memory locations that are not defined by he input program. In particular, it will define and use new locations to hold values that it decides to spill from registers to memory. The input blocks receive data in one of two ways. Either the values are is hard-coded into theblock, or they are specified on the simulator’s command line using the -i command-line option.The concepts and algorithms behind register allocation are explained in two distinct places.First, there are a series of short videos available on the course Canvas Site. You should watcheach of these videos. Second, Chapter 13 in the textbook explains register allocation in depth.Sections 13.1 and 13.2 provide background and Section 13.3 presents, in detail, the algorithmsthat pertain to Lab 2. You should read this material. An excerpt from Section 13.3 is posted on
Canvas. (The later sections of Chapter 13 describe global allocation, the more complex problemthat arises when the allocator looks at code that includes control-flow operations.)Lab 2: Local Register Allocation Version 2024-1COMP 412Fall 2024
This document describes the specifications for your program, the policies for the lab, thevarious logistics associated with the lab, the process for submitting the lab,and the gradingrubric. The document is long, but you should read it to ensure that you understand what isexpected of your lab and what tools are available to help.
- Overview of the Problem
A register allocator is a compiler pass that transforms a version of the program that uses anarbitrary number of registers into a version that uses a specified number of registers. That is,he input program might be written to use seventy-three registers and the output program canonly use the number of registers available for application use on the target machine.The number of registers available for the output program is a parameter, called k, that is passed
nto the allocator on the command line. When invoked with a command line, such as
./412alloc 17 ~comp412/students/ILOC/SLOCs/T001k.1
The allocator should read the file, ~comp412/students/ILOC/SLOCs/T001k.i, determine if it is avalid ILOC block, and produce an equivalent block that uses at most 17 registers.To transform the program, the register allocator reads through the operations in the block andmakes, at each operation, a decision as to which values should remain in registers and whichvalues should be relegated to storage in memory. It inserts stores (spills) and loads (restores) asnecessary to ensure that the values are in the right places. It rewrites the code to use thenames of the actual hardware registers (r0 through r16 for the example command line).Your allocator may not apply optimizations other than register allocation. All the loads, stores,and arithmetic operations that appear in the input program must appear in the outputprogram, in the same relative order. 1 The output block must perform the original computation;it cannot pre-compute the results. Allocators that perform optimizations other than register allocation will lose substantial credit. Of course, the output block may use different registernames than the input block.Your allocator may remove nops; they have no effect on the equivalence of the input andoutput of programs. If your allocator performs rematerialization (see the Lab 2 PerformanceLecture), then it may move loadI operations around in ways that cannot happen with a load ora store. Finally, your allocator must not perform optimizations based on the input constantsspecified in ILOC test block comments; the autograder may use different input values to test
your code.To evaluate your submission, we will use an autograder — a fairly-straightforward pythonprogram that will unpack your submission, perform any actions needed to build the executable,and test your executable against a series of test blocks. We will provide a distribution of the
autograder so that you can verify that your submission works with the autograder. Theproduction autograder will use additional files, not available in the distributedutograder, toassess your submission.1We say “relative order” because the allocator may insert spills and/or restores between any twooperations in the original program.Lab 2: Local Register Allocation Version 2024-1COMP 412Fall 20243
- Code SpecificationsYour allocator must adhere to the following specifications.
- Name: The executable version of your allocator must be named 412alloc.
- Behavior: Your allocator must work in following three modes:
412alloc -h When passed the -h flag, 412alloc must print a list of the valid command
line arguments that it accepts, along with a concise explanation for that option. That listhould include the arguments described in this table, as well as any others that yourallocator supports. After printing the message, 412alloc should sto.
412alloc -x <name> The -x flag will only be used for Code Check 1. Again, <name>
is a Linux pathname. With this flag, 412alloc should scan and parse the input block. Itshould then perform renaming on the code in the input block and print the results tothe standard output stream (stdout). lab2_ref does not implement the -x flag.
412alloc k <name> In this format, k is the number of registers available to the
allocator (3 ≤ k ≤ 64) and <name> is a Linux pathname to the file containing the inputlock. The pathname can be either a relative pathname or an absolute pathname.If k is outside the valid range or it cannot open the file specified by <name>, 412allochould print a reasonable error message and exit cleanly (e.g., no backtrace).If the parameters are valid, 412alloc should scan parse, and allocate the code in theinput block so that it uses only registers r0 to rk-1 and print the resulting code to thestandard output stream (stdout).In each mode, 412alloc should check the input parameters and report any problems on thestandard error stream (stderr). All error messages should be printed to the standard errorstream (stderr). Normal output should be printed to the standard output stream (stdout).
- Input File: The input file will consist of a sequence of ILOC operations (a block) in the subset
described in § A. If 412alloc cannot read the input file, or the code in the file is not valid
ILOC, it should write an error message to the standard error file (stderr). 412alloc should
detect as many errors in the file as it can before quittingIf the ILOC code in the input block uses a value from a register that has no prior definition,your allocatorshould handle the situation gracefully.Scanning and Parsing: Your register allocator should use your front end from Lab 1 to read
and parse the input file. The front end should be prepared to handle large input files, suchas the file T128k.i from Lab 1 (also found in ~comp412/students/ILOC/Scalability/SLOCs/).
Makefile & Shell Script: As in Lab 1, you will submit a tar archive file that contains the
source code for your allocator, along with any scripts or Makefiles required to create and
execute the final code.2 For a Java lab, you must submit the code, not a jar file.
2
If you prefer to use another build manager (available on CLEAR), invoke that build manager in your Makefile. Your
build manager should not leave behind a repository— particularly hidden files in comp412’s home directory.Lab 2: Local Register Allocation
Version 2024-1
COMP 412
Fall 2024
4
Lab 2 submissions written in languages that require a compilation step, such as C, C++, or
Java, must include a Makefile. The autograder will invoke make with the two commands:
make clean
make build
in that order. The clean target should remove any files from old attempts to build theexecutable. The build target should ensure that the 412alloc executable is ready to run. Iyour submission is written in a language that does not require compilation, such as python,then it does not need a Makefile.
If your submission does not create a standalone executable named 412alloc, then it should
nclude a shell script named 412alloc that accepts the required command-line argumentsand passes them to the program. For example, a project written in python3 named lab2.pycould provide an shell script named 412alloc that includes the following instructions:
#!/bin/bash
python3 lab2.py $@
To invoke python2, you would use the command “python2” rather than “python3”.
Similarly, a project written in Java with a jar file named lab2.jar or a class named lab2.class
that contains the main function could provide, respectively, one of the following two
executable shell scripts, naming it 412alloc.
#!/bin/bash
#!/bin/bash
java -jar lab2.jar $@
java lab2 $@
To ensure that your 412alloc shell script is executable on a Linux system, execute the
following command in the CLEAR directory where your 412alloc shell script resides:
chmod a+x 412alloc
To avoid problems related to the translation of carriage return and line feed between
Windows and Linux, we strongly recommend that you write your shell script and Makefile
on CLEAR rather than on a Windows system (see also man dos2unix).
- README: Your submission must include a file named README (uppercase letters, no suffix)
that provides directions for building and invoking your allocator. Include a description of allcommand-line arguments required for Lab 2 as well as any additional command-linearguments that your allocator supports. The autograder expects that the first two lines of
your README file are in the following format:
//NAME: <your name>
//NETID: <your netid>
Note that there are no spaces after the slashes, and that the keywords NAME and NETID are in all capital letters. Your name should be capitalized normally. Your netid should be
lowercase characters and numbers.
3 Alternatively, you can write a python program that runs directly. As an example, see the lab 1 testing script on
CLEAR. Its first line is a comment that tells the shell to invoke python; the main routine parses argv and argc.Lab 2: Local Register Allocation
Version 2024-1
COMP 412
Fall 2024
5
- Programming Language: You may use any programming language provided on Rice’s CLEAR
facility, except for Perl. Your goal should be to use a language that is available on CLEAR, in
which you are comfortable programming, for which you have decent debugging tools, and
that allows you to easily reuse code in Lab 3. When coding, be sure to target the version of
your chosen programming language that is available on CLEAR.
- USE CLEAR: Your submission must work on CLEAR. If the code must be translated (e.g.,
compiled, linked, turned into a jar or an a.out), that must happen on CLEAR. Test the code
on CLEAR; test it in the distributed autograder. Students have, in previous years, found
differences between language and library versions on their laptops and on CLEAR.
- Code Checks
Lab 2 has two intermediate code checks. To pass a code check, you should run the appropriate
script (see below) and submit a screen shot to the code check assignment on Canvas. The code
checks are intended to keep your progress on track, time wise. You get full credit at the due
date, half credit two days late, and no credit beyond two days late. Grace days do not apply.
(The grading rubric is discussed in § 5.)
Code Check #1: The due date for code check #1 is shown on page 1. To pass code check #1,
412alloc must correctly scan, parse, perform register renaming, and print the resulting
renamed ILOC block to stdout. The code check #1 script and test blocks are located on
CLEAR in the directory ~comp412/students/lab2/code_check_1/.
Code Check #2: The due date for code check #2 is shown on page 1. To pass code check #2,
412alloc must correctly perform register allocation on a limited set of test blocks. (That is,
the allocated code must produce the correct answers when run with only k registers on the
ILOC simulator.) The code check #2 script and the test blocks are found in
~comp412/students/lab2/code_check_2/.
The code check directories on CLEAR contain a README file that describes how to invoke the
code check script and interpret the results. As before, you may need an executable shell script
that to conform to the interface. A working Makefile is not critical for the code checks, but we
recommend that you create your Makefile or script before the first code check and use it while
developing your code.
- Submitting Your Final Code
Due date: The due date for your code submission is shown on page 1. All work is due at
11:59PM on the specified day. Individual extensions to this deadline will not be granted.
Early-Submission Bonus: Submissions received before the due date will receive a bonus of one
semester point (1% of the final course grade).
Late Penalty: Submissions received after the due date will receive a penalty of one semester
point (1% of the final course grade). No code will be accepted after the date when the next
project is made available. Lab 2: Local Register Allocation Version 2024-1COMP 412Fall 20246
Grace Days: To cover situations that inevitably arise, we 代 写COMP 412 Local Register Allocation Table of Contentswill waive up to four days of lateenalties per semester when computing your final COMP 412 grade. Note that we choosewhere those days apply, after all grades are complete. We will apply these “grace” days in a
way that maximizes benefit to you.Submission Details: To submit your work, you must create a tar archive that contains your
submission, including (1) the source code for the register allocator, (2) the Makefile and/orshell script, (3) the README file, and (4) any other files that are needed for the autograder tobuild and test your code. The tar file should unpack into the current working directory. The
README, Makefile, and executable script, if any, must reside in that top-level directory.
The document “NoteOnTarFiles.pdf”, available on the COMP 412 Canvas Site, provides moredetails about the structure of the submission file system and the tar archive. You can testyour archive using the autograder. If your archive does not work with the autograder, thatwill reduce the points you receive in the conformance portion of the grading rubric.If your allocator does not work, include in your tar file a file named STATUS that contains a
brief description of its current state. You may include ILOC files that your lab handlescorrectly and ILOC files that it handles incorrectly. List those file names in theSTATUS file.Name the tar file with your Rice netid (e.g., if your netid is jed12, you would name thearchive jed12.tar). To submit your tar file, move it to CLEAR and execute the command
~comp412/bin/submit_2 <tar file name> The submit_2 script will create a copy of your tar archive, timestamp it, and send an email
confirmation to you and to the comp412 email account (for record-keeping). You shouldkeep the tar archive until the end of the semester to record what yousubmitted.
- Grading Rubric
The Lab 2 grade accounts for 20% of your final COMP 412 grade. The code rubric is based on100 points, allocated as follows. Correctness and cycle count will be determined using the Lab 2
ILOC simulator.
- 10 points for passing code check #1 by its due date (see table on page 1). 5 points will bewarded for passing code check #1 within three days of the due date. No points for codecheck #1 will be awarded after that time. Grace days do not apply to thisdeadline.
- 10 points for passing code check #2 by its due date (see table on page 1). 5 points will beawarded for passing code check #2 within three days of the due date. No points for codecheck #2 will be awarded after that time. Grace days do not apply do this deadline.
- 10 points for conformance to the Lab 2 code specifications and submission requirements.
- 30 points for correctness of the allocated code produced by the final submission. Here,
correctness means that running the allocated code produces the correct answer.
- 20 points for effectiveness, measured as the number of cycles required to run the
allocated code produced by your final submission on the Lab 2 ILOC simulator. An
allocator that gets within 10% of the cycle counts for lab2_ref will receive full credit for Lab 2: Local Register Allocation
Version 2024-1
COMP 412
Fall 2024
7
effectiveness. You can use the spreadsheet Lab2SpreadSheet.xlsx, in the lab 2
documents folder, to estimate effectiveness on the report blocks. The report blocks are a
subset of the blocks used to grade your allocator.
- 20 points for performance, split equally between scalability and efficiency. The autotimer
measures performance using blocks from ~comp412/students/ILOC/Scalability/SLOCs.
The autotimer is included with the distributed autograder.
Scalability: The register allocator should display linear scaling — that is, a doubling of the
input size should produce growth of no more than 2x in the runtime. You can see this by
plotting runtime as a function of non-comment lines in the input file; do not use a
logarithmic scale on either axis.
Efficiency: The table below shows the measured runtime on block T128k.i required for full
credit and the time that will produce zero credit. Runtimes between full credit and zero
credit will receive partial credit, on a linear scale between the breakpoints. The specific
breakpoints were determined by analyzing the lab 2 submissions from the Fall 2020 class.
Language
Full Credit
No Credit
C
£ 1.0 second
³ 2.0 seconds
C++
£ 2.0 second
³ 4.0 seconds
Java
£ 4.75 seconds ³ 12.0 seconds
Python
£ 8.0 seconds
³ 20.0 seconds
Go
£ 1.0 second
³ 2.0 seconds
For languages not shown in the table, the instructor will determine a set of breakpoints
based on the language, its implementation, and, perhaps, some additional testing.
- Honor Policy
Your submitted source code and README file must consist of code and/or text that you wrote,
not edited or copied versions of code and/or text written by others or in collaboration with
others. You may not look at COMP 412 code from past semesters. Your submitted code may
not invoke the COMP 412 reference allocator, or any other allocator that you did not write.
You are free to collaborate with current COMP 412 students when preparing your Makefile
and/or shell script and to submit the results of your collaborative Makefile and/or shell script
efforts. However, as indicated in the previous paragraph, all other Lab 2 code and text
submitted must be your own work, not the result of a collaborative effort. You may not use
tools based on generative AI to assist you in creating the code for your allocator.
You are welcome to discuss Lab 2 with the COMP 412 staff and with students currently taking
COMP 412. You are also encouraged to use the archive of test blocks produced by students in
previous semesters. However, we ask that you not make your COMP 412 labs available to Lab 2: Local Register Allocation
Version 2024-1
COMP 412
Fall 2024
8
students (other than COMP 412 TAs) in any form during or after this semester. We ask that you
not place your code anywhere on the Internet that is viewable by others.
Appendix A. ILOC Simulator & Subset
ILOC Simulator: An ILOC simulator, its source, and documentation are available in the subtree
under ~comp412/students/lab2 on CLEAR. The source code and documentation are available.
If you need to build a private copy of the simulator, § 7.1 of the simulator documentation
explains the various configuration options.
The simulator builds and executes on CLEAR. You can either run the simulator from comp412’s
directory or copy it into your local directory. You can build a copy to run on your laptop. It
appears to work on other OS implementations but that is not guaranteed. Your allocator will be
tested and graded on CLEAR, so you should be sure to test it on CLEAR.
ILOC Subset: Lab 2 input and output files consist of a single basic block4 of code written in a
subset of ILOC, detailed in the following table. ILOC is case-sensitive.
Syntax
Meaning
Latency
load
r1
=> r2 r2 ß MEM(r1)
3
loadI
x
=> r2 r2 ß x
1
store
r1
=> r2 MEM(r2) ß r1
3
add
r1, r2 => r3 r3 ß r1 + r2
1
sub
r1, r2 => r3 r3 ß r1 - r2
1
mult
r1, r2 => r3 r3 ß r1 * r2
1
lshift
r1, r2 => r3 r3 ß r1 << r2
1
rshift
r1, r2 => r3 r3 ß r1 >> r2
1
output x
prints MEM(x) to stdout
1
nop
idle for one cycle
1
All register names have an initial lowercase r followed immediately by a non-negative integer.
Leading zeros in the register name are not significant; thus, r017 and r17 refer to the same
register. Arguments that do not begin with r, which appear as x in the table above, are assumed
to be non-negative integer constants in the range 0 to 231 – 1. The assignment arrow is
composed of an equal sign followed by a greater than symbol, as shown (=>).
Each ILOC operation in an input block must begin on a new line and be completely contained on
that line. 5 Whitespace is defined to be any combination of blanks and tabs. ILOC opcodes must
4
A basic block is a maximal length sequence of straight-line (i.e., branch-free) code. We use the terms block and
basic block interchangeably when the meaning is clear.
5
Both Carriage returns (CR, \r, 0x0D) and line feeds (LF, \n, 0x0A) may appear as in end-of-line sequences.Lab 2: Local Register Allocation
Version 2024-1
COMP 412
Fall 2024
9
be followed by whitespace. Whitespace preceding and following all other symbols is optional.
Whitespace is not allowed within operation names, register names, or the assignment arrow. A
double slash (//) indicates that the rest of the line is a comment and can be discarded. Empty
lines and nops in input files may also be discarded.
Memory Use in the ILOC Simulator: The ILOC simulator has separate address spaces for code
and data. The code memory is not accessible to a running ILOC program; this unreasonable
restriction avoids a class of errors in the allocated code that are quite difficult to debug.
The simulator only supports word-aligned accesses—that is, the address must be evenly
divisible by four. For this assignment, addresses above 32,767 are reserved for the register
allocator to use as spill locations. Any values that an ILOC test block stores to memory (other
than spills) must use an address between 0 and 32,764, inclusive.
For more details, see the ILOC Simulator document, in ~comp412/students/lab2/simulator/ on
CLEAR.
Simulator Usage Example: If test1.i is in your present working directory, you can invoke the
simulator on test1.i in the following manner to test your register allocator:
/clear/courses/comp412/students/lab2/sim -r 5 -i 2048 1 2 3 < test1.i
This command will cause the simulator to execute the instructions in test1.i, print the values
corresponding to ILOC output instructions, and display the total number of cycles, operations,
and instructions executed.
The -r parameter is optional and restricts the number of registers the simulator will use. (In the
example, the simulator only uses 5 registers, named r0, r1, r2, r3, and r4.). You can use the –r
parameter to verify that code generated by your allocator uses at most k registers. You should
not use -r when running the original (non-transformed) report and timing blocks.
The -i parameter is used to fill memory, starting at the memory address indicated by the first
argument that appears after -i, with the initial values listed after the memory address. The load
and store operations available in the ILOC subset require word-aligned addresses (that is,
addresses must be evenly divisible by 4). The example command line shown above initializes
location 2048 to 1, location 2052 to 2, and location 2056 to 3. (If the first operation in block
test1.i is "output 2048", the simulator will print the value 1 to stdout.) When computing
addresses for new spill locations, your allocator must generate word-aligned addresses.
The simulator’s -x parameter will be used to verify that your allocator passes the Lab 2 code
check. For example, if your 412alloc implementation produces a file of renamed ILOC code
called renamed_block.i, the following command can be used to check whether renaming was
correctly performed:
/clear/courses/comp412/students/lab2/sim -x < renamed_block.i
See the ILOC simulator document for additional information about supported command-line
options. (Note that the command-line options -d, -s, and -c are not relevant for Lab 2.)Lab 2: Local Register Allocation
Version 2024-1
COMP 412
Fall 2024
10
ILOC Input Blocks: A large collection of ILOC input blocks is available on CLEAR, in the directory
~comp412/students/ILOC/. Each block has the //SIM INPUT: and //OUTPUT: specifications to
allow the various testing scripts to check for correctness. If you experience problems with the
input blocks, please submit bug reports to the course Piazza site.
To estimate your allocator’s performance, you may want to use the report blocks, which are
available on CLEAR in ~comp412/students/lab2/report/. The report blocks all appear in the
production autograder’s test suite. The autotimer uses a subset of the blocks found on CLEAR in
~comp412/students/ILOC/Scalability/SLOCs/.
- Tools
B.1 Reference Allocator
To help you understand the functioning of a local register allocator and to provide an exemplarfor your implementation and debugging efforts, we provide a reference allocator, lab2_ref. Thereference allocator is a C implementation of the allocator. It follows the basic outline of thealgorithm presented in class; it pays careful attention to how it generates spill code. You can
improve your understanding of register allocation by examining its output on small blocks. Theoutput code includes comments that are intended to help you understand what it did.
The reference allocator is an example. You do not need to duplicate its behavior, its results, or
the allocations that it produces.
You can use the reference allocator to determine how well your allocator performs in terms of
effectiveness (the number of execution cycles that the simulator reports when it runs the code
that your allocator generates) and efficiency (the runtime of your allocator itself).
The COMP 412 reference allocator can be invoked on CLEAR as follows:
~comp412/students/lab2/lab2_ref k <name>
where k is an integer (3 £ k £ 64) that specifies the number of registers available to the
allocator and <name> is a valid Linux pathname relative to the current working directory that
names an input file. For a description of the complete set of flags supported by the COMP 412
reference allocator, enter the following command on CLEAR:
~comp412/students/lab2/lab2_ref –h
Note that the COMP 412 reference allocator can only be run on CLEAR.
B.2 Testing and Timing Scripts
Scripts to test your allocator’s correctness and efficiency are available on CLEAR in the directory
~comp412/students/lab2/. Directions are provided in the related README files.Lab 2: Local Register Allocation Version 2024-1COMP 412Fall 202411
- Timing Results from Prior Years
The graphs below show the timing results for the fastest implementation written in each of C,
C++, Java, Python, and Go, from Fall 2021. In addition, we include graphs for Ruby (2014),OCaml (2015), Haskell (2015), and R (2014). These graphs should provideyou with a reasonablenotion of what kind of efficiency a student can achieve in the allocator project.Note the units on the vertical axes of the graphs. They change significantly between languages.
Allocation Time (seconds)Lab 2: Local Register Allocation Version 2024-1
COMP 412Fall 202413Checklist for Lab 2
The following high-level checklist is provided to help you track your progress on Lab 2.
£ Implement a bottom-up local register allocator based on the algorithm in § 13.3 of
Engineering a Compiler, 3rd Edition, and the project videos. Submit your allocator by
October 23, 2024.
£ Use the ILOC simulator, described in § A-1, to ensure that the allocated code produced by
your program is correct—that is, it produces an equivalent sequence of operations as
described on page 1—and to measure the number of cycles that the ILOC simulator requires
to execute the allocated block. A large library of ILOC test blocks is available for you to use
when testing your allocator in comp412’s students/ILOC subtree on CLEAR.
£ Test your allocator thoroughly on CLEAR. It will be graded on CLEAR.
£ Ensure that your code passes Lab 2 code check #1. To pass the code check, your code mustcorrectly scan, parse, perform register renaming, and print the resulting renamed ILOCblock to stdout. To receive full credit, submit results that demonstrate that your allocatorpasses code check #1 on or before October 4, 2024. £ Ensure that your code passes Lab 2 code check #2. To pass the code check, your code mustconform to the interface described in § 3 and must perform register allocation correctly and
print the resulting allocated ILOC block to stdout. To receive full credit, submit results thatdemonstrate that your allocator passes code check #2 on or before October16, 2024.
£ Spend the rest of your time improving the effectiveness of the allocator, as measured bythe number of cycles that the simulator reports when it runs the allocated code, and theefficiency of the allocator, as reported by the autotimer.To produce an grade, we will run the allocator on each of the report blocksand on a set of private blocks. We will test each code with k set to 3, 4, 5, 6, 8, and 10. Thenumber of points awarded to an allocator for effectiveness will be based on a comparisonof thecycle counts produced by the allocator and the cycle counts produced by lab2_ref on
the same input file and k value.
Change History: 2024-1 posted on 09/23/202
标签:will,code,COMP,Register,Lab,Allocation,ILOC,your,allocator From: https://www.cnblogs.com/comp9021/p/18439807