DETECTION AND REMOVAL OF MEMORY LEAKS FOR JAVA
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Detection And Removal Of Memory Leaks For Java Script
DETECTION AND REMOVAL OF MEMORY LEAKS FOR JAVA
SCRIPT
1
HIRAY ROHINI D., 2MAHALE SAYALI K., 3PINGALE ANUJA R., 4TAMBE VIJAYSHREE C.
1,2,3,4
Department of Computer Engineering, K.K.Wagh Institute Of Engineering Education And Research , Nashik, India
Abstract— JavaScript is the dominant language for implementing dynamic web pages in browsers. In JavaScript, a memory
leak causes because of different issues like, program allocates more memory than necessary for its execution, some objects
are not in used but stays in memory for longer time, memory allocated inside a function or class method and which is not de-
allocated before the function completes and many more. A memory leak is the failure to release memory that has been
allocated to a program. Over time, a memory leak will result in progressively less memory being available to perform valid
functions. Both Firefox and older versions of Internet Explorer have a history of memory leaks that would persist until the
browser was closed. However, today there is a different trend that affects memory leakage. This project work aims at
developing techniques for finding and fixing the memory leaks problem to increase CPU performance. The work also aims at
combining predict that arises from different patterns to possibly improve the performance. For resolving the problem of
memory leaks the proposed solution will Find Out, Identify and Fix the different types of memory leaks. The System
enhanced with the feature of compatibility, means it is compatible or portable with any web browser and any web user and
web developer can use it.
Index Terms— Optimization, Performance, Static Analysis, Memory Leak, JavaScript.
I. INTRODUCTION conditions (and it is not that hard to do so, as we will
see shortly). Internet Explorer is the king of leakers.
When a program needs to store some temporary Each browser has its own strengths and weaknesses.
information during execution, it can dynamically For instance, Mozilla consumes too much of memory
request a chunk of memory from the system. at initial boot, it is not good in string and array
However, the system has a fixed amount of total operations; Opera may crash if you write a
memory available. If one application uses up all of the ridiculously complex DHTML script which confuses
systems free memory, then other applications will not its rendering engine. Memory leaks are usually hard to
be able to obtain the memory that they require. It is detect for developer because they are caused by some
the responsibility of each application to free unintentional mistakes within large amount of code
dynamically requested memory when they are and it does not affect the functionality of the
finished using it. Freeing the memory returns it to the application until the memory starvation occurs in the
system, where it can be reallocated to another system. The paper is organized as follows: In section
application when needed. When an application II the Concept of Memory Leak In JavaScript are
dynamically allocates memory, and does not free that briefly described. Section III describes relates
memory when it is finished using it, that program has Motivation Example which causes the Memory Leaks
a memory leak. JavaScript is a powerful scripting .Need of Fixing Memory Leaks described in Section
language used to add dynamic content to Web pages. IV. In section V we also describe in detail the
It is especially beneficial for everyday tasks such as identified seven problem patterns and their resolution
password validation and creating dynamic menu Section VI; VII covers implementation and their
components. While JavaScript is easy to learn and related work. We conclude in section VIII.
write, it is prone to memory leaks in certain browsers.
In JavaScript Memory leak refers to memory allocated II. CONCEPT OFMEMORY LEAKS IN
for the application which is unable to be reallocated JAVASCRIPTS
even after its not being used. Normally, garbage
collectors collect the DOM elements and event JavaScript (JS) is an interpreted computer
handlers when they are not referenced or unreachable. programming language. As part of web browsers,
However, memory leaks are unforgiving for earlier implementations allow client-side scripts to interact
versions of IE, IE 7and before, because the memory with the user, control the browser, communicate
manager does not understand the JavaScript cycle and asynchronously, and alter the document content that is
will not reclaim the memory until the cycles are displayed. JavaScript is almost entirely object-based
broken explicitly which can be done by assigning to language. A web browser is by far the most common
null. The problem of memory leakage is not just host environment for JavaScript. Web browsers
limited to Internet Explorer. Almost any browser typically create "host objects" to represent the
(including but not limited to Mozilla, Netscape and Document Object Model (DOM) in JavaScript. The
Opera) will leak memory if you provide adequate web server is another common host environment.
Proceedings of 5th IRF International Conference, Chennai, 23rd March. 2014, ISBN: 978-93-82702-67-2
1Detection And Removal Of Memory Leaks For Java Script
Because JavaScript is the only language that the most bringing the entire browser down. Each browser has
popular browsers share support for, it has become a its own strengths and weaknesses. For instance,
target language for many frameworks in other Mozilla consumes too much of memory at initial boot,
languages. Despite the performance limitations it is not good in string and array operations; Opera
inherent to its dynamic nature, the increasing speed of may crash if you write a ridiculously complex
JavaScript engines has made the language a DHTML script which confuses its rendering engine.
surprisingly feasible compilation target.
In the browser JavaScript world, a memory leak 1.Object Graph
occurs when the native garbage collection routines All values in JavaScript are part of the object graph.
don’t properly reclaim the memory that was allocated The graph begins with roots, for example, the window
for an object. Each time you create an object in object. Managing the lifetime of GC roots is not in
JavaScript, a bit of memory is allocated. Memory is your control, as they are created by the browser and
also allocated for DOM nodes, COM objects, images, destroyed when the page is unloaded. Global variables
etc. When an object can no longer be accessed, it is are actually properties on window.
flagged as “ready for removal.” Then the garbage
collection routine sweeps up the flagged objects, and 2.When Does a Value Become Garbage?
releases the memory back to the system. Internet A value becomes garbage when there is no path from
Explorer and Mozilla Firefox are the two Web a root to the value. In other words, starting at the roots
browsers most commonly associated with memory and exhaustively searching all Object properties and
leaks in JavaScript. The culprit in both browsers is the variables that are alive in the stack frame, a value
component object model used to manage DOM cannot be reached, it has become garbage. Shown in
objects. Both the native Windows COM and Mozilla's Figure (2).
XPCOM use reference-counting garbage collection
for memory allocation and retrieval. Reference
counting is not always compatible with the mark-and-
sweep garbage collection used for JavaScript.
Memory leaks are usually hard to detect for developer
because they are caused by some unintentional
mistakes within large amount of code and it doesn’t
affect the functionality of the application until the
memory starvation occurs in the system. It is why
there is performance testing when performance
metrics of the application are collected during a long
term testing period. Figure 1.Object Graph
III. MOTIVATING EXAMPLE
The problem of memory leakage is not just limited to
Internet Explorer. Almost any browser (including but
not limited to Mozilla, Netscape and Opera) will leak
memory if you provide adequate conditions. But
Internet Explorer is the king of leakers. Each browser
has its own strengths and weaknesses. For instance,
Mozilla consumes too much of memory at initial boot,
it is not good in string and array operations; Opera
may crash if you write a ridiculously complex
DHTML script which confuses its rendering engine. Figure 2.Garbage Value
While JavaScript employs garbage collection for
automatic memory management, it is not a substitute A memory leak in JavaScript most commonly occurs
for effective memory management in applications. when there are DOM nodes that are not reachable
JavaScript applications suffer from the same memory from the page’s DOM tree, but are still referenced by
related problems that native applications do, such as a JavaScript object. While modern browsers are
memory leaks and bloat, yet they must also deal with making it increasingly difficult to inadvertently create
garbage collection pauses. Large-scale applications leaks, it’s still easier than one might think. Let’s say
like Gmail encounter the same problems facing your you append an element to the DOM tree like this:
smaller applications. The Gmail team was facing a email.message = document.createElement(“div”);
serious problem. Anecdotes of Gmail tabs consuming displayList.appendChild(email.message); And later,
multiple gigabytes of memory on resource- you remove the element from the display list:
constrained laptops and desktops were being heard displayList.removeAllChildren(); Listing 1.DOM
increasingly frequently, often with a conclusion of tree Element
Proceedings of 5th IRF International Conference, Chennai, 23rd March. 2014, ISBN: 978-93-82702-67-2
2Detection And Removal Of Memory Leaks For Java Script
A.Measuring Memory at Scale of bugs: unbounded caches, infinitely growing arrays
Gmail instrumented their JavaScript to use the of callbacks waiting for something to happen that
performance .memory API to collect memory never actually happens, and event listeners
information approximately once every 30 minutes. unintentionally retaining their targets. By fixing these
Because many Gmail users leave the app up for days issues, the overall memory usage of Gmail was
at a time, the team was able to track memory growth dramatically reduced. Users in the 99% percent used
over time as well as overall memory footprint 80% less memory than before and the memory
statistics. Within a few days of instrumenting Gmail consumption of the median users dropped by nearly
to collect memory information from a random 50%.
sampling of users, the team had enough data to
understand how widespread the memory problems
were among average users. They set a baseline and
used the stream of incoming data to track progress
toward the goal of reducing memory consumption.
Eventually this data would also be used to catch any
memory regressions.
Beyond tracking purposes, the field measurements
also provide a keen insight into the correlation
between memory footprint and application
performance. Contrary to the popular belief that
“more memory results in better performance”, the
Gmail team found that the larger the memory
footprint, the longer latencies were for common Gmail
actions. Armed with this revelation, they were more
motivated than ever to rein in their memory
consumption. Figure 5.Resolving Gmail’s Memory Crisis
Because Gmail used less memory the GC pause
latency was reduced, increasing the overall user
experience. Also of note, with the Gmail team
collecting statistics on memory usage, they were able
to uncover garbage collection regressions inside
Chrome. Specifically, two fragmentation bugs were
discovered when Gmail’s memory data began
showing a dramatic increase in the gap between total
memory allocated and live memory.
IV. WHY SHOULD NEED TO FIX MEMORY
Figure 3. Memory growth for a single user over 4 days after LEAKS?
starting Gmail. The y-axis shows memory growing up to 1.5GB
over those 4 days Fixing memory leaks often reveals buffer overruns,
buffer underruns, memory corruptions, calling
functions on deleted objects (which will lead to
indeterminate behaviour), multiple access to memory
that was freed (incorrect memory access problems).
Fixing these problems then results in an overall boost
in application software quality, reliability and
robustness.
Fixing memory leaks improves your application’s
memory footprint allowing it to run for longer without
errors and failures of operation. This in turn leads to
greater user/customer satisfaction. One proposed
solution to memory leaks is to use garbage collection.
Figure 4. Increasing latency variability and magnitude caused Garbage collection removes the responsibility of
by memory bloat during the same time span . Theyaxis denotes deallocating memory from the programmer. Well, that
time per request in [sec], which ranges from 0 up to 12 seconds.
is the theory. The reality is that garbage collected
B. Resolving Gmail's Memory Crisis languages and technologies (.Net, C#, Java, Python,
By using the tools and techniques discussed above, Ruby, etc) can all suffer from memory leaks caused
the Gmail team was able to identify a few categories by the programmer forgetting to set references to
Proceedings of 5th IRF International Conference, Chennai, 23rd March. 2014, ISBN: 978-93-82702-67-2
3Detection And Removal Of Memory Leaks For Java Script
objects to NULL when they have finished with them. We refer to an object graveyard where objects with an
Garbage collection simply changes the cause of the Event-Handler or event listeners attached, are added
memory leak from forgetting to deallocate the to an
memory to forgetting to reset the reference to NULL. array/list and remain in this data structure long past
Either way the memory gets leaked. However the fix their lifetime/use. In some of these cases the
for deterministic memory leaks is often much easier to containing data
determine whereas for garbage collected memory structure is traversed and these objects disposed of,
leaks identifying where reset object references is not but just because it willget disposed of eventually, does
always so easy. not mean it won’t result in memory bloat.
V. PATTERNS OF MEMORY LEAK X. prototype. addNotification = function (t) {
if (! goog . array . contains ( onInvalidate_ , t)) {
1.Disposing Event Handler this . onInvalidate_ . push (t);
Event Handler provide a simple mechanism to group }
all events and listeners associated with an object };
together. This allows for easy removal of listeners
when the events being listened to can no longer fire. Listing 2. Object graveyard.
Hence this is main sources of leak. Consider the This pattern is quite problematic, as it also
following scenario. We wish to pop-up a new dialog corresponds to many valid usage patterns. In fact,
when the user presses a button. The DOM tree without further semantic information as to the lifetime
representing the new dialog is created and an event or use of the objects being stored into the array, one
listener is added to the dialog containing the button, could not determine if code corresponding to the
associating the button click event with displaying the pattern was a leak or not.
dialog. Here, a link (reference) is created between the
DOM object being listened to, the DOM tree of the 4.Local EventHandler
new dialog, the JavaScript object A local EventHandler instance that does not escape
model of the containing dialog and the Event Handler. scope, e.g., a locally defined variable that is not
If the button can no longer be clicked, say the dialog assigned to a field member, added to an array, or
has been destroyed, then that event can no longer fire. captured in a closure, can not be disposed of later.
But if the programmer did not dispose of the Event A common instance of this pattern is locally created
Handler (e.g., by calling the Closure dispose () Event Handler objects which listen to events using the
function), then the DOM tree corresponding to the member function listen once. The listen Once call
new dialog is still referenced and cannot be reclaimed. attaches an event listener to an object such that event
This problem corresponds directly to the classic listener is removed if the trigger action does occur.
memory allocation pattern in C++, which requires Conceptually this avoids memory leaks as the event is
matching automatically unlistened to and the object can be
new and delete calls. But, as JavaScript is garbage reclaimed by the garbage collector. But this is only
collected, programmers are not necessarily aware of true if the event is guaranteed to occur. If the event
the requirements for cleanup when disposing objects never occurs then the event listener is never removed
and simply forget, or overlook, the need to make those and the object is
matching calls. never reclaimed.
2.Setting Member to NULL 5.Leaked data member
In JavaScript setting a variable to null is the idiomatic This is memory allocated for use by a class member,
way of providing a hint to the garbage collector that but which is not deallocated before the class object is
the memory allocated by an object can be reclaimed. destroyed.
But the Event- Handler and event listeners attached to class comms Handle
the object prevents the garbage collector from {
disposing of the object and reclaiming memory. public:
In all instances where the developer wishes to free an commsHandle();
Event Handler, he/she has to explicitly dispose of the ~commsHandle();
object rather than just setting the variable to null. void setName(char *p_name);
From the observed problem cases, we believe that void createCommsHandle();
programmers were not fully aware of the explicit private:
requirement to dispose of objects for cleanup. Instead HANDLE handle;
they relied on the garbage collector, which is not able char *name;
to free all resources ad listeners, which led to memory };
leaks. commsHandle::commsHandle()
{
3.Object Boneyard name = NULL;
Proceedings of 5th IRF International Conference, Chennai, 23rd March. 2014, ISBN: 978-93-82702-67-2
4Detection And Removal Of Memory Leaks For Java Script
handle = NULL; ~commsHandle();
} static void flushName();
commsHandle::~commsHandle() static void setName(char *p_name);
{ void createCommsHandle();
if (handle != NULL) private:
CloseHandle(handle); HANDLE handle;
} static char *name;
void commsHandle::setName(char *p_name) };
{ void commsHandle::flushName()
size_t len; {
len = strlen(p_name); if (name != NULL)
name = new char [len + 1]; {
if (name != NULL) delete [] name;
{ name = NULL;
strcpy(name, p_name); }
} }
} void commsHandle::setName(char *p_name)
The above class has two problems: {
1. the destructor does not deallocate the memory flushName();
allocated in size_t len;
setName(). len = strlen(p_name);
2. setName() does not deallocate the memory name = new char [len + 1];
allocated in if (name != NULL)
setName() prior to allocating a new value for name. {
Solution:commsHandle::~commsHandle(){ strcpy(name, p_name);
if (handle != NULL) }
CloseHandle(handle); }
if (name != NULL)
delete [] name;} Listing 4.Leaked class static data member
void commsHandle::setName(char *p_name){ With the above solution commsHandle::flushName()
if (name != NULL){ needs to be called during program shutdown (or at the
delete [] name; end of main()).
name = NULL;}
size_t len; 7. Leaked global memory
len = strlen(p_name); This memory is allocated for use by many functions
name = new char [len + 1]; and is not part of a class.
if (name != NULL) char *name;
{ strcpy(name, p_name); void setName(char *p_name)
} size_t len;
} len = strlen(p_name);
name = new char [len + 1];
Listing 3.Leaked Data member if (name != NULL)
{
6.Leaked class static data member strcpy(name, p_name);
For these pattern refer above Listing 3. This memory }
is allocated for use only by many functions of a class, }
but shared across all instances of that class.The above Solution:
class has two problems: char *name;
1. setName() does not deallocate the memory void flushName()
allocated in setName() prior to allocating a new value { if (name != NULL)
for name. {
2. there is no function to deallocate the memory delete [] name;
allocated in setName() – it is not possible to call a name = NULL;
function to cleanup this memory allocation. }
}
Solution: void setName(char *p_name)
class commsHandle {
{ flushName();
public: size_t len;
commsHandle(); len = strlen(p_name);
Proceedings of 5th IRF International Conference, Chennai, 23rd March. 2014, ISBN: 978-93-82702-67-2
5Detection And Removal Of Memory Leaks For Java Script
name = new char [len + 1]; broad and too restrictive, though it does serve the
if (name != NULL) intuition. Denote the set of classes that are eventful by
{ EC, then a class, A, is considered eventful if.
strcpy(name, p_name);
} Intrinsically eventful
} • A has an unmatched listen call (this includes A
listening to events using an anonymous function or
Listing 5.Leaked Global Memory returned from call to goog.bind);
With the above solution flush Name () needs to be • A removes event listeners/handlers during disposal;
called during program shutdown (or at the end of input : Type-annotated AST G = (V; A; vtype)
main()). output : List of potential leaks
In this way these are different seven patterens of // Seed eventful set
Memory Leaks. EC {goog.events.EventHandler};
// Initialize eventize DAG
VI. IMPLEMENTATION EG (all types,Ø);
// Construct eventize DAG
As discussed above Memory leak is a common foreach type t ε V do
unintentional programming mistake in large web Et {};
applications. if t is eventful locally then EC EC U {t};
Memory leaks reduce the performance of a web foreach type r that eventize t do
application until it becomes unusable when the wasted Et (r, t);
memory grows beyond what the system can afford. As end
a web developer, developing a web application to // Add eventize arcs of t to EG
meet the functional requirements is just the first step, A[EG] A[EG] U Et;
performance requirements are as important for the end
success of a web application, not to mention the propagate eventful property using EG;
possible failure of the application or a browser crash. // Find potential leaks
Different pattrens of memory leaks are observed in foreach object o created in G do
many web applications. Proposed system provides a skip if o is filtered;
solution to handle the causes of memory leaks.The if type[o] ε EC then
implementations covers the different solutions as: if o is private member overwritten or
The Closure Compiler is a tool for making JavaScript o is not disposed
download and run faster. It is a true compiler for then record error
JavaScript. Instead of compiling from a source end
language to machine code, it compiles from end
JavaScript to better JavaScript. It parses your return errors reported
JavaScript, analyzes it, removes dead code and Algorithm 1: Overview of JSWhiz.
rewrites and minimizes what's left. It also checks Eventized
syntax, variable references, and types, and warns • A is of type goog.events.EventHandler (the seed
about common JavaScript pitfalls. The Closure member of EC);
Compiler reduces the size of your JavaScript files and • A extends a class B 2 EC; or
makes them more efficient, helping your application • A has a class member of type B 2 EC which is
to load faster and reducing your bandwidth needs. It disposed of when A is disposed of. As we are
also provides warnings for illegal JavaScript and implementing system as open source using a
warnings plug-in, is a software component that adds a specific
for potentially dangerous operations, helping you to feature to an existing software application.
produce JavaScript that is less buggy and easier to
maintain. VII. RELATED WORK
JSWhiz’s detection centers around the concept of
eventful classes, which we shall describe next. A As we mentioned in the introduction, the common
high-level overview of the approach is outlined in occurrence and serious consequences of memory leaks
Algorithm 1.Using this concept,we were able to track have resulted in a large body of research describing
above patterns described. techniques for detecting them. Memory leaks and
memory bloat have been researched extensively in the
Eventful classes past. Besides publications, there are many open-
The above patterns we found could be encapsulated source tools and commercial solutions. Much of this
within the concept of, what we shall call, an eventful work targets C++, or Java and other garbage collected
class. languages. Most existing leak detection techniques for
Intuitively an eventful class is one which has events C and C++ applications only detect the existence of
associated with it. But such a definition is both too memory leaks.
Proceedings of 5th IRF International Conference, Chennai, 23rd March. 2014, ISBN: 978-93-82702-67-2
6Detection And Removal Of Memory Leaks For Java Script
The new technique tracks pointers to dynamically JSWhiz was tested across 7 major JavaScript
allocated areas of memory and, for each memory area, applications and found 89 bugs in production code.
records several pieces of relevant information. This Fixing of the bugs identified by JSWhiz contributed to
information is used to identify the locations in an more than 75% reduction in 99th percentile memory
execution where memory leaks occur. usage of Gmail, and more than 50% at the median.
To investigate these technique’s feasibility and The latency impact at the higher percentiles is
usefulness, we developed a prototype tool called impossible to break out, but removing leaks certainly
LEAKPOINT and used it to perform an empirical contributed to an observed 10% improvement at the
evaluation. The results of this evaluation show that 95th percentile.
LEAKPOINT detects at least as many leaks as Our discussion is mostly specific to detecting a
existing tools, reports zero false positives, and, most memory leaks in javascript.ie. many Browser For ex.
importantly, can be effective at helping developers fix IE. The system increasing the actual CPU
the underlying memory management errors. a two- Performance as well as Browser Speed. Be cognizant
phase approach to the online memory leak detection of the memory use in your application and you will
problem for Java programs. In phase one (offline have more reliable and better performing applications.
analysis), the user executes the investigated program We hope our work raises awareness in the community
for a while and analyzes its heap with the proposed and hope that open-sourcing our implementation will
agent. The agent then summarizes the total occupied spawn interesting further research.
bytes of data structures in the heap offline, and the
user is then able to select classes whose object REFERENCES
instances seem to be potential leaks by examining the
total occupied bytes summary. In phase two (online [1] wo-Phase Online Memory Leak Detection Jui-Shan Liang_,
Hung-Wei Kaoy, Han-Ching Tsaoz, Shao- Chen Changz,
monitoring), to reduce the space and time overhead at
Meng-Hsun Tsaiy, Kuan-Hsien Liy and Yingrong Coral
runtime, the agent monitors online the objects of Sung
selected classes instead of monitoring all objects in [2] Hamilton, Naomi (2008-06-31). "The A-Z of Programming
the heap. The approach reports the last accessed time Languages: JavaScript". Computer world. com.au.
[3] LEAKPOINT: Pinpointing the Causes of Memory Leaks -
and location (including the source file name and the
James Clause and Alessandro Orso -ICSE ’10, May 2-8
line number) of each leak candidate, with which the 2010.
user can identify and fix leaks in the program. [4] jQuery memory leak patterns and causes, 2011. URL
http://stackoverflow.com/questions/5046016.
[5] jQuery memory leak patterns and causes, 2011. URL
CONCLUSION http://stackoverflow.com/questions/5046016.
[6] A. Bhattacharya and K. S. Sund. Memory leak patterns in
In this paper we have presented patterns that lead to JavaScript.http://www.ibm.com /developerworks/web/
memory leaks in JavaScript applications, approaches library/wa-memleak/, 2007.
[7] I. Schlueter. Memory leaks in Microsoft Internet Explorer,
to finding and fixing them, and recommended
2007. URL http://foohack.com/2007/06/msie-memory-
practices for avoiding them in the first place. We leaks/.
introduced JSWhiz, a tool to statically analyze [8] M. Jump and K. S. McKinley. Cork: Dynamic memory leak
JavaScript applications and identify potential memory detection for garbage-collected languages. POPL ’07, pages
31–38, New York, NY, USA, 2007. ACM.
leaks. [9] http://Effectively%20managing memory at Gmail scale –
HTML5 Rocks.htms
Proceedings of 5th IRF International Conference, Chennai, 23rd March. 2014, ISBN: 978-93-82702-67-2
7You can also read
