KR20150089746A - Memory menagement apparatus and method of java script - Google Patents
Memory menagement apparatus and method of java script Download PDFInfo
- Publication number
- KR20150089746A KR20150089746A KR1020140010725A KR20140010725A KR20150089746A KR 20150089746 A KR20150089746 A KR 20150089746A KR 1020140010725 A KR1020140010725 A KR 1020140010725A KR 20140010725 A KR20140010725 A KR 20140010725A KR 20150089746 A KR20150089746 A KR 20150089746A
- Authority
- KR
- South Korea
- Prior art keywords
- area
- memory
- garbage collection
- javascript
- present
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Memory System (AREA)
- Devices For Executing Special Programs (AREA)
- Debugging And Monitoring (AREA)
Abstract
Description
[0001] The present invention relates to a device for managing a memory of a JavaScript and a method thereof, and more particularly, to a method and apparatus for managing a memory of JavaScript by efficiently performing garbage collection on an aperiodic basis or periodically, And a method for managing the memory of the JavaScript.
Along with the breakthrough in hardware performance, the use of virtual machines has been greatly improved. Typically, there are Oracle's Java Virtual Machine, Google's Android Dalvik Virtual Machine, and a JavaScript Virtual Machine, which is built into the Web browser.
In the case of Java, the source code with the extension java is compiled by the Java compiler into an intermediate representation of the bytecode. The extension of this bytecode has a class. Bytecode is code that is hardware platform independent and runs on a virtual machine that is dependent on each hardware / software platform. Therefore, software developers have the advantage of being able to develop regardless of platform. However, there is a problem that execution speed is lowered due to a problem that is executed on a virtual machine.
In the case of JavaScript, source code such as JavaScript sent from the server will run in a virtual machine called the JavaScript engine without compilation process. In fact, the JavaScript engine contains the process of parsing, parsing, and transforming the source code, and has a mechanism that is immediately compiled (just-in-time) to run at runtime. Although JavaScript has the advantage of being able to be developed on a platform-independent basis like Java, it has a disadvantage that execution speed is very slow in terms of concurrent compilation operation that is converted into machine language at runtime.
C / C ++ developers can use mallock, free, new, and delete functions to allocate or free memory for a desired amount of memory. However, Java or JavaScript developers can allocate memory, but there is no function to do so. Therefore, the virtual machine needs to investigate the memory allocated to the objects that are not used any more periodically or acyclic, and inform the system so that the memory can be efficiently managed. This process is called garbage collection.
This garbage collection provides program developers with the following benefits: The memory is released at the development stage, preventing invalid data from being read at the time of access to the invalid pointer, or releasing the memory again without knowing that the memory is released or releasing the memory at the appropriate time. It is possible to prevent the program from stopping due to a large memory area. On the contrary, in order for the virtual machine to perform garbage collection, there is an additional cost of checking and releasing the unused memory area, and it is not possible to know when the accurate garbage collection is performed, So that optimization is difficult.
In this regard, Korean Patent Laid-Open Publication No. 2008-0016058 discloses a " device and method for memory management of a Java virtual machine ".
SUMMARY OF THE INVENTION The present invention has been made to solve the above problems, and it is an object of the present invention to provide a device for managing a memory of JavaScript that divides a memory into a plurality of areas and performs garbage collection for moving a newly allocated object from the area to the area, The purpose is to provide.
It is another object of the present invention to provide a memory management apparatus and method for a JavaScript that performs garbage collection for releasing objects other than marked objects in a final area from a memory.
According to an aspect of the present invention, there is provided an apparatus for managing a memory of a JavaScript, the apparatus comprising: a region dividing unit dividing a memory into a plurality of regions; A garbage collection performing unit for searching a reference path of an object to be newly allocated and moving the reference path to another area; And a memory management unit for determining whether to perform marking of an object according to whether or not a reference path exists for an object moved to the last area and determining whether to release the memory, A memory area is divided into a second area storing an object moving in the first area, a third area storing an object moving in the second area, and a fourth area storing an object moving in the third area. .
According to an aspect of the present invention, there is provided a method for managing a memory of a JavaScript, the method comprising: dividing a memory into a plurality of regions by an area division unit; Checking a reference path of a newly allocated object by a garbage collection performing unit and moving the reference path to another area; And a step of determining whether to release a memory by determining whether to perform marking of an object according to whether a reference path exists for an object moved to the last area by the memory management unit and dividing the memory into a plurality of areas A first area storing an object to be newly allocated, a second area storing an object moving in the first area, a third area storing an object moving in the second area, and an object moving in the third area And the fourth region is divided into memories.
An apparatus and method for managing a JavaScript according to the present invention having the above-described structure divides a memory into a plurality of regions and performs garbage collection for moving a newly allocated object from the region to the region, Can be prevented.
In addition, the present invention has an effect of efficiently managing the memory area by releasing the objects other than the marked objects in the old area from the memory.
1 is a view for explaining garbage collection performed through reference path tracing according to the present invention.
FIG. 2 is a diagram illustrating a configuration of a JavaScript memory management apparatus according to an embodiment of the present invention. Referring to FIG.
3 is a diagram illustrating a memory structure of a JavaScript memory management apparatus according to an embodiment of the present invention.
4 is a diagram for explaining the area occupation and movement of objects in the memory of the JavaScript memory management apparatus according to the embodiment of the present invention.
5 is a view for explaining a flow of operations related to garbage collection in a memory management apparatus for JavaScript according to an embodiment of the present invention.
6 is a flowchart illustrating a method of managing a memory of a JavaScript according to an embodiment of the present invention.
The present invention will now be described in detail with reference to the accompanying drawings. Hereinafter, a repeated description, a known function that may obscure the gist of the present invention, and a detailed description of the configuration will be omitted. Embodiments of the present invention are provided to more fully describe the present invention to those skilled in the art. Accordingly, the shapes and sizes of the elements in the drawings and the like can be exaggerated for clarity.
Hereinafter, an apparatus and method for managing a JavaScript according to an embodiment of the present invention will be described in detail with reference to the accompanying drawings.
1 is a view for explaining garbage collection performed through reference path tracing according to the present invention.
Referring to FIG. 1, in the present invention, each local variable, static variable or global variable in the stack memory or register is referred to as a root set of references. This can be seen as the first starting point in the path to follow. It is a method to keep track of the reference path in the heap memory area from such a root object, to distinguish the accessible object from the impossible object by determining whether each memory is referenced, and then to release the last inaccessible memory area. There are four types of garbage collection through reference as follows.
First, the Mark and Sweep Algorithm is a simplest method among reference methods. A 1-bit memory for a mark is placed in a memory, and when the corresponding object is being used in the inspection step, the mark bit is displayed as '1' Otherwise, after marking '0', when the whole memory test is finished, the mark bit is determined by checking the mark bit and the memory is released.
Second, the Tri-color Mark Algorithm adds a mark that means that the mark-breaking and basic mechanism are the same, but that objects on the heap memory have not yet been checked. This corresponds to the case shown in Fig. All objects in the heap memory are grayed out before performing the garbage collection operation, and each time the check is performed, the object is referenced and displayed in white if it is in use and black when it is not in use. When the check is complete, objects marked black are unlocked.
Third, the Moving Algorithm refers to moving the available objects to another area of memory after checking the object. The heap memory area is divided into two, and the available objects in one area are moved to another area, and then the existing areas are all released in memory.
Fourth, generational algorithms are presented in the program code under the fact that objects with newly allocated memory are likely to be released immediately. In the case of dividing memory into two regions, Objects are allocated to a memory area called an Eden space and then moved to an old space if used continuously. The memory structure according to the present invention is presented in this structure.
That is, the present invention proposes a method for performing dedicated hardware garbage collection in association with the generation movement technique among the garbage collection algorithms mainly used in web applications written in JavaScript.
FIG. 2 is a diagram illustrating a configuration of a JavaScript memory management apparatus according to an embodiment of the present invention. Referring to FIG.
Referring to FIG. 2, the JavaScript
The region dividing unit divides the memory into a plurality of regions. The region dividing unit divides the memory into a first region, a second region, a third region, and a fourth region. In addition, it may further include a permanent space storing a JavaScript application execution code at the end.
The garbage collection execution unit examines the reference path of the newly allocated object and moves it to another area. The garbage collection execution unit examines the reference path of the object stored in the first area, moves the surviving objects to the second area, examines the reference path of the object stored in the second area, and moves the surviving objects to the third area The garbage collection is performed for a predetermined number of times, and then the surviving object is moved to the fourth area.
The memory management unit determines whether or not to perform marking of the object according to whether a reference path exists for the object moved to the last area and decides whether to release the memory. The memory management unit examines the reference path of the object stored in the fourth area, marks the object on which the reference path exists, and does not mark the object on which the reference path does not exist. Therefore, the memory management unit releases the remaining objects except the marked object from the memory.
3 is a diagram illustrating a memory structure of a JavaScript memory management apparatus according to an embodiment of the present invention.
Referring to FIG. 3, the memory according to the present invention is divided into a plurality of areas by the area dividing unit.
The memory is divided into a first area, a second area, a third area, a fourth area, and a permanent area.
The first area stores newly allocated objects when a JavaScript application is executed. In the present invention, the first region is defined as the eden region.
The second area is a survival area of the object, and objects surviving in the first area are stored. In the present invention, the second region is defined as a survival region.
The third region is a survival region of the object, and the objects surviving in the second region are stored. In the present invention, the third region is defined as a survival region.
The fourth area is an area in which objects surviving in the third area are stored. In the present invention, the fourth area is defined as an Old area.
The persistent area is an area where JavaScript application execution code is stored, and is an area where garbage collection is not performed.
4 is a diagram for explaining the area occupation and movement of objects in the memory of the JavaScript memory management apparatus according to the embodiment of the present invention.
Referring to FIG. 4, the occupancy and movement of objects according to the present invention are likely to be deleted immediately after execution of most of the objects in the code executed in the JavaScript application, Objects that survive the area move to the second area. Next, both the first area and the second area are examined, and the objects including the reference path are moved to the third area.
At this time, the garbage collection in the first to third areas is performed using the object movement technique. This is referred to as Minor Garbage Collection in the present invention. Minor garbage collection is performed very frequently, and object movement is active in memory.
In this manner, after the garbage collection is performed for a predetermined number of times in the first to third areas, the object surviving until the last is moved to the fourth area. The garbage collection in the fourth area examines the object, marks the object to be examined by the reference path, and does not mark an object that does not have a reference path, so that after the inspection of all objects, Release to memory.
At this time, garbage collection in the fourth area is performed using a mark and release algorithm. In the present invention, this is referred to as a major garbage collection. A major garbage collection examines all objects in the region.
5 is a view for explaining a flow of operations related to garbage collection in a memory management apparatus for JavaScript according to an embodiment of the present invention.
Referring to FIG. 5, in the flow of operation related to the garbage collection according to the present invention, in the case of the minor garbage collection, software is operated by the processor core, and in the case of the major garbage collection, a dedicated garbage collector is used. A dedicated garbage collector can form the processor core's cache memory high-speed interface and control the memory controller through the system bus.
For high-speed operation of garbage collection, the minor garbage collection operates on the cache memory, and the major garbage collection operation operates the main memory through the memory controller of the system bus.
The processor core can also initiate and stop major garbage collection, and the garbage collector will notify the processor when major garbage collection operations are complete.
6 is a flowchart illustrating a method of managing a memory of a JavaScript according to an embodiment of the present invention.
Referring to FIG. 6, the memory management method of JavaScript according to the present invention uses a JavaScript memory management device as described above, and a duplicate description will be omitted.
First, when a program is requested to allocate an object to the heap area of the memory, a new object is stored (S100).
Next, in step S200, it is determined whether there is an unallocated space by using a free list. If there is an empty space, one of empty spaces is allocated in step S210. However, in step S200, If there is not enough free space, the system is told to perform garbage collection operations.
Next, after the application is stopped, garbage collection is started (S300).
Next, it is determined whether there is a reference path of the object from the reference root set stored in the stack or register (S400)
Next, the object having the reference path performs the mark and updates the mark list (S500, S510). After the step S510, the updated mark list can be checked and the free list can be updated.
Next, an object that does not have a reference path performs memory release without performing a mark (S600).
As described above, the apparatus and method for managing memory of JavaScript according to the present invention divide a memory into a plurality of areas and perform garbage collection for moving a newly allocated object from the area to the area, thereby preventing fragmentation of the memory area have.
In addition, the present invention can efficiently manage the memory area by releasing the objects other than the marked objects in the old area from the memory.
While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is evident that many alternatives, modifications, and variations will be apparent to those skilled in the art without departing from the scope of the appended claims. As will be understood by those skilled in the art.
100: JavaScript's memory management device
110: area dividing unit 120: garbage collection performing unit
130:
Claims (1)
A garbage collection performing unit for searching a reference path of an object to be newly allocated and moving the reference path to another area; And
And a memory management unit for determining whether or not to perform marking of the object according to presence or absence of a reference path of the object moved to the last area and determining whether to release the memory,
Wherein the area division unit comprises:
A first area storing an object to be newly allocated, a second area storing an object moving in the first area, a third area storing an object moving in the second area, and a second area storing an object moving in the third area, Wherein the memory is divided into four areas.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR1020140010725A KR20150089746A (en) | 2014-01-28 | 2014-01-28 | Memory menagement apparatus and method of java script |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR1020140010725A KR20150089746A (en) | 2014-01-28 | 2014-01-28 | Memory menagement apparatus and method of java script |
Publications (1)
Publication Number | Publication Date |
---|---|
KR20150089746A true KR20150089746A (en) | 2015-08-05 |
Family
ID=53886122
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
KR1020140010725A KR20150089746A (en) | 2014-01-28 | 2014-01-28 | Memory menagement apparatus and method of java script |
Country Status (1)
Country | Link |
---|---|
KR (1) | KR20150089746A (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108958943A (en) * | 2018-07-25 | 2018-12-07 | 北京小米移动软件有限公司 | Memory release method and device |
KR102453983B1 (en) * | 2021-12-14 | 2022-10-31 | 인터와이즈 주식회사 | method for garbage collection based on survival path information |
-
2014
- 2014-01-28 KR KR1020140010725A patent/KR20150089746A/en not_active Application Discontinuation
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108958943A (en) * | 2018-07-25 | 2018-12-07 | 北京小米移动软件有限公司 | Memory release method and device |
CN108958943B (en) * | 2018-07-25 | 2021-02-09 | 北京小米移动软件有限公司 | Memory release method and device |
KR102453983B1 (en) * | 2021-12-14 | 2022-10-31 | 인터와이즈 주식회사 | method for garbage collection based on survival path information |
WO2023113267A1 (en) * | 2021-12-14 | 2023-06-22 | 인터와이즈(주) | Survival path information-based garbage collection method |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8612493B2 (en) | Allocation cache premarking for snap-shot-at-the-beginning concurrent mark-and-sweep collector | |
CN110892378B (en) | Global variable migration through virtual memory overlay techniques during multi-version asynchronous dynamic software updates | |
US8995070B2 (en) | Garbage collection based on functional block size | |
US10417097B2 (en) | System and method for creating selective snapshots of a database | |
US7500077B2 (en) | Use of region-oriented memory profiling to detect heap fragmentation and sparse memory utilization | |
US8484630B2 (en) | Code motion based on live ranges in an optimizing compiler | |
US7913243B2 (en) | Method and system for generating and applying patches to a computer program concurrently with its execution | |
US8397045B2 (en) | Memory management device, memory management method, and memory management program | |
EP4012568A1 (en) | System and method for dynamically selecting a garbage collection algorithm based on the contents of heap regions | |
JP5896952B2 (en) | Method, apparatus and computer program for managing memory | |
JP6080826B2 (en) | Method for influencing the control program of a control unit | |
KR20150089746A (en) | Memory menagement apparatus and method of java script | |
US10628301B1 (en) | System and method for optimizing write amplification of non-volatile memory storage media | |
US9411566B2 (en) | System and method for removal of arraycopies in java by cutting the length of arrays | |
US20160378508A1 (en) | Jni object access | |
Norlinder et al. | Compressed Forwarding Tables Reconsidered | |
US20150378799A1 (en) | Automatic memory leak detection | |
Deldon et al. | OpenACC and CUDA unified memory | |
KR100735560B1 (en) | Apparatus and method for controlling virtual memory | |
CN101763308A (en) | Pool allocation method for heap data at running time | |
CN109643276A (en) | Create the system and method for database subset snapshot | |
US7117318B1 (en) | Memory management | |
EP2960798B1 (en) | Automatic memory leak detection | |
CN105242978A (en) | Method and device for processing failure of cache lines of CPU under multi-thread condition | |
JP5891963B2 (en) | Address management apparatus and program |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
WITN | Withdrawal due to no request for examination |