Memory Allocation Methods - Half 1 > 자유게시판

• 목록
• 답변
• 글쓰기
• 게시판 리스트 옵션
  • 수정
  • 삭제

Memory allocation appears to be something many people wrestle with. Many languages attempt to mechanically handle memory for you utilizing totally different methods: garbage collection (GC), automated reference counting (ARC), useful resource acquisition is initialization (RAII), and possession semantics. Nevertheless, making an attempt to summary away memory allocation comes at a better price than most individuals understand. Most individuals are taught to think about memory in terms of the stack and the heap, the place the stack is mechanically grown for a procedure name, and the heap is a few magical thing that you need to use to get memory that should dwell longer than the stack. This dualistic strategy to memory is the fallacious solution to give it some thought. It offers the programmer the mental mannequin that the stack is a special form of memory1 and Memory Wave that the heap is magical in nature. Fashionable working methods virtualize memory on a per-course of foundation. Which means that the addresses used within your program/course of are specific to that program/course of solely.

Due to working programs virtualizing the memory space for us, this enables us to consider memory in a completely completely different method. Memory isn't longer this dualistic mannequin of the stack and the heap however rather a monistic model the place every little thing is digital memory. A few of that digital tackle space is reserved for procedure stack frames, a few of it is reserved for issues required by the operating system, and the remaining we can use for whatever we wish. This will sound similar to authentic dualistic model that I said beforehand, nevertheless, the most important distinction is realizing that the memory is nearly-mapped and linear, and that you could split that linear memory area in sections. Lifetime Identified), that is the world through which I can be covering the most in this collection. More often than not, you do know the size of the allocation, MemoryWave or the higher bounds a minimum of, and the lifetime of the allocation in question.

Lifetime Known), that is the world during which chances are you'll not know how a lot memory you require but you do know how lengthy you can be using it. The most common examples of this are loading a file into memory at runtime and populating a hash table of unknown size. Chances are you'll not know the quantity of memory you will want a priori and as a result, you could need to "resize/realloc" the memory so as to suit all the info required. In C, malloc et al is a solution to this domain of issues. Lifetime Unknown), that is the area by which chances are you'll not know how lengthy that memory needs to be round but you do know how a lot memory is needed. In this case, you could possibly say that the "ownership" of that memory throughout multiple techniques is ill-defined. A common resolution for this area of issues is reference counting or possession semantics. Lifetime Unknown), this is the area by which you might have actually no concept how much memory you need nor how long it is going to be needed for.

In observe, this is kind of uncommon and you should attempt to avoid these situations when doable. However, the general answer for this area of problems is rubbish collection3. Please notice that in area particular areas, these percentages can be utterly completely different. As an illustration, an online server that could be dealing with an unknown quantity of requests may require a type of rubbish collection if the memory is restricted or it could also be cheaper to only purchase extra Memory Wave. For the widespread class, the overall strategy that I take is to think about memory lifetimes by way of generations. An allocation generation is a means to prepare memory lifetimes right into a hierarchical structure4. Permanent Allocation: Memory that is never freed until the end of this system. This memory is persistent throughout program lifetime. Transient Allocation: Memory that has a cycle-based lifetime. This memory only persists for the "cycle" and is freed at the top of this cycle. An instance of a cycle may very well be a body inside a graphical program (e.g. a recreation) or an replace loop.