Total execution time in different design

Finally, total execution time (including GC, pure execution, and overhead) is presented. N is 320 Kbytes, too.

0 200 400 600 800 1000 1200 1400

16 24 32 64 128

Heap Size (KBytes)

GC times Original JVM

Stack Allocation My Design

Figure 4.4: Total execution time in different design

We can see that in memory constrained environment, we can improve speed about 11%, even including overhead in speed. However, when the heap size is 128 Kbytes, the overhead will become bigger than the improvement in my design. The total execution time in my design is even worse than original Java Virtual Machine and Stack Allocation when heap size is 128 Kbytes

.

Figure 4.5: (GC time + overhead in speed) in different design

0 Times of mininal execution heap size

Cycle counts

Original JVM Stack Allocation My Design

9 11

After discussion about total execution time in different design, we knows that when size of memory is large, my design will become useless, or even harmful to speed performance. So, let us see the range of heap size which we should adopt our design. Figure 4.5 is (GC time + overhead in speed) in different design. (GC time + overhead in speed) is (total execution time – unchanged execution time), which unchanged execution time is the pure execution time (excluding GC) in original Java virtual machine. And the minimal execution heap size without error of our benchmark is 11 Kbytes. It helps us to see the curve of execution time with different heap size in different mechanism clearly. We can see that we become worse than original Java Virtual Machine when heap size is bigger than 11 times of minimal execution heap size. And it becomes worse than Stack Allocation when bigger than 9 times of minimal execution heap size.

4.5.4 Overheads

Overhead to Total Execution Time

0.0%

16K 24K 32K 64K 128K

Heap Szie (bytes)

Additional overhead in compact Phase

Reseting end of local objects

Recording end of local objects

Figure 4.6: Ratio of overhead to total execution time in my design

Then let us discuss about additional overhead when adopting my design. We can see figure 4.6, in my simulation, the overhead is 0.6% ~ 0.9%. And about 95%

of overhead is to record and reset end of local objects in local chunk list when method invocation and return. Only 5% of additional overhead is because the modification of garbage collector in compact phase. It occupies more little portion in memory constrained environment because the total execution time in memory constrained environment is larger. But amount of overhead in different heap size is similar because most portion of it is to record and reset end of local objects in local chunk list when method invocation and return, and number of method invocation and return is invariant to heap size. It means that overhead is invariant to heap size.

So, the more we can improve in reducing frequency of Garbage Collection, the more we can improve in total execution time.

Chapter 5 Conclusions

In this thesis, a mechanism to free all identified local objects in heap is purposed and evaluated.

First, we propose the mechanism to allocating Local Objects in heap but not stack to avoid the constraint in current approach and then discuss about meted problems when we add it to original Java Virtual machine. Finally, we evaluate my design with

simulation and make some conclusions by observing results in my simulation..

As a result, we can see that: (1) In a system with memory constraints, allocating Local Objects in heap is better than in stack to reduce frequency of garbage collection.

It brings improvement about speedup on total execution time. (2)If heap is large enough, my design have less chance to improve the speed performance. Moreover, overhead of my design will make modified JVM even slower than the original JVM and Stack Allocation mechanism.

So, my design is suitable for memory constrained system. In our simulation, in a memory constrained environment, my design leads to 11% speedup over original Java Virtual Machine and reduce 60% of Garbage Collection in vocation counts, and 7%

speedup over Stack Allocation on total execution time.

However, if heap is large, my design becomes less useful than memory constrained environment, or even harmful to speed performance. But what is the range of size of heap which is appropriate to adopt my design? In our simulation, we can see that if heap size is less than 11 times of minimal execution heap size, my design is better than original Java Virtual Machine in speed issue. If heap size is less than 9 times of minimal execution heap size, my design is better than Stack Allocation in speed issue. So, we can know when we should adopt our design.

And in overhead issue, it shows that overhead of my design is about 0.6% ~ 0.9%

of total execution time, which varies because the variation of total execution time. And most portion of my overhead is to record and reset end of local objects in local chunk list, when method invocation and return. So, we can focus on it if we want to reduce the overhead.

In future work, to make our design suitable for all system but not only memory constrained system, we can design a mechanism to dynamically profile the ratio of garbage collection time to execution time to figure out whether JVM will adopt my design in runtime. It can helps to turn off my design to reduce overhead when there are not too opportunities to improve. However, the overhead of this mechanism should be considered, too. And the threshold to turn on or turn off my design is also an issue should be discussed.

Besides freeing Local Objects in heap upon method return to reduce overhead of Garbage Collection., allocating Local Objects in the same method contiguously may also helpful in locality in environment which has cache system because objects in the

access objects in heap because data may had been cached. This issue can be a further research to be discussed, too.

References

[1] C. E. McDowelt* , “Reducing garbage in Java” Volume 33 , Issue 9 (September 1998) , Pages: 84 - 86 ,Year of Publication: 1998

[2] Tim Lindholm, Frank Yellin “The Java^TM Virtual Machine Specification”. http://

http://java.sun.com/docs/books/vmspec/html/VMSpecTOC.doc.html

[3] Sun Microsystems, Inc , “J2Me Building Blocks for Mobile Devices – White Paper on KVM and the Connected, Limited Device Configuration (CLDC)” 901 San Antonio Road, Palo Alto, CA 94303 USA, 650 960-1300 fax 650 969-9131, May 19, 2000

[4] 探矽工作室著, 深入嵌入式 Java 虛擬機器 Inside KVM 學貫行銷股份有限公司出 版, 2002[民 91]

[5] Joshua Engel, Tim Lindholm, Java Virtual Machine, 1 edition, O'Reilly; (April 1, 1997) [6] Erik Corry, “Stack Allocation for Object-Oriented Languages” Daimi University of

Aarhus, Denmark [email protected] ,May 24, 2004

[7] David Gay, Bjarne Steensgaard, ”Stack Allocating Objects in Java”, Microsoft Technical Report, November 1998