To measure the runtime of the application, the configuration of the CDxcollision detector was set to calculate collisions in 50 radar frames. The time used for each frame is measured by the program. The percentual overhead for each frame was then calculated for both the weavelet-based CoffeeBreak as well as the CoffeeBreak that is implemented purely in Java. The results can be seen in Figure 4.1.
4.3 Runtime of the Application 49
Figure 4.1 – Percentual runtime overhead for each frame of the CDx applica-tion.
The results show that the weavelet-based implementation of the CoffeeBreak garbage collector has a runtime for each frame that is on average 36 % higher than that of the C implementation. The implementation using a Java-based approach for the GC’s own data structures is significantly faster, with an average overhead of only 11 % compared to the native C implementation of the CoffeeBreak.
The spike in the overhead for the first frame is caused by the fact that the time taken for its calculation is much lower than that of the other frames. Deviations in execution time for this first frame therefore show much more prominently than those of other frames.
Consequently, the wide-spread use of weavelets for CoffeeBreak can only be dis-couraged: It comes with a huge penalty on performance. The additional complexity incurred by adding a Java Domain Zero however is well justified: It more than halves the time overhead incurred by implementing the GC in Java.
50 4.3 Runtime of the Application
textdatabsstotalsize/Byteincrease/%size/Bytesincrease/%size/Bytesincrease/%size/Bytesincrease/%
CDx(standardCoffeeBreak)42476–1977–992882–1037335–CDx(weaveletCoffeeBreak)440403.6820292.639949960.2110410350.36CDx(RDS-heapCoffeeBreak)463209.05234918.8210285023.5910771713.84
Table4.2–Sizeofsystemswithdifferentgarbagecollectors,groupedbythesegmentofthebinary.TheincreaseinsizeisgiveninpercentcomparedtothebinaryusingthestandardimplementationoftheCoffeeBreakGC.
Chapter 5
Conclusion
This thesis evaluated the possibility of implementing KESO’s garbage collection services in the type-safe language Java instead of C. To do so, changes were not only made to the implementation of the actual garbage collectors but they were also needed in all three stages of KESO’s compiler, JINO.
In a first step, the task was analyzed: Related work of garbage collection in type-safe languages was reviewed and common problems found in the Jalapeño/Jikes RVM, Singularity OS and Squawk VM projects were identified. Among them are especially the need to provide low-level access to memory in Java and to restrict Java’s object allocation. Additional problems stem from language differences between Java and C.
JINO’s previously existing stack allocation was reused. An additional mechanism in the compiler was implemented to restrict the garbage collector implementations in Java that were then implemented to stack allocation. In this process, KESO’s memory-mapped objects were discarded as a method to provide low-level system access, as they showed to be too inflexible. KESO’s weavelets were used instead.
This implementation heavily relied on weavelets, not only for accessing system properties but also for storing garbage collection data structures. As this was deemed unsatisfactory, a new approach was developed that allows the garbage collector to use an allocation-only heap that is reset at pre-defined points in the algorithm.
Additionally, a way of expanding the garbage collector’s code using object-oriented patterns instead of conditional compilation was shown.
In conclusion, the initial problems identified in the analysis could be circum-vented, and it was shown that writing garbage collection in Java for KESO is certainly possible. However, the development proved to be cumbersome due to KESO’s nature:
As KESO’s runtime system is written in C (contrary to related systems), weavelets have to be written for virtually any system interaction. In addtion, KESO’s fine-grained configurability that relies both on procedural generation of program code by
51
52 5 Conclusion
JINO, as well as conditional compilation, complicates propagation of configuration options to the Java code of the garbage collector.
Future Work
Resetting the RDS heap in the final, dynamic implementation of the CoffeeBreak garbage collector has two drawbacks: The programmer must make sure that no object references into the re-usable area of the heap survive. They must also manually determine the points in the algorithm where the base set has been allocated and where resetting the heap is appropriate.
To improve the safety of the resettable RDS heap, it would be interesting to evaluate whether additional compiler passes could automatically identify the point in code where the reset should occur. The base set could be identified by data flow analysis. JINO could then insert the necessary instructions automatically.
Another area that shows potential for improvement is the propagation of KESO’s configuration to the Java implementation of the garbage collectors. As shown in Section 3.4.5, it is possible to re-create configuration options present in the original CoffeeBreak collector. However, the class that implements the desired option has to be selected manually by the user.
To facilitate option passing and be able to access constants read from KESO’s configuration file or determined during the compilation process, a preprocessor could be included. Other projects, such as the Squawk VM presented in Section 2.1.3, already have a working preprocessor for Java. It would be interesting to evaluate if this preprocessor could be used for KESO.
List of Acronyms
GC garbage collector JVM Java Virtual Machine
KESO “Konstruktiver Speicherschutz für eingebettete Systeme“ – German for ”Con-structive memory protection for embedded systems“
RDS Restricted Domain Scope RE runtime environment TCB Trusted Code Base
53
List of Figures
1.1 The architecture of KESO (source: [1]). . . 3 1.2 Structure of an object in KESO . . . 4 2.1 Structure of an RDS heap and schematic of an allocation . . . 12 2.2 Heap of a CoffeeBreak managed domain. The free list is embedded
in the free memory blocks (source: own work). . . 14 3.1 Class structure of the static CoffeeBreak GC. Classes implemented
using weavelets are marked with «weavelet». . . 34 3.2 Methods of the CoffeeListElement class . . . 35 3.3 Structure of the new Domain Zero implementation . . . 37 3.4 CoffeeBreak GC: Separation between allocation and collection . . . . 39 3.5 Class structure of the dynamic CoffeeBreak GC. Classes implemented
using weavelets are marked with«weavelet« . . . 40 3.6 Cyclically resetting the RDS heap of the Java Domain Zero. . . 41 3.7 Structure of the logging CoffeeBreak GC. . . 42 4.1 Percentual runtime overhead for each frame of the CDxapplication. . 49
55
List of Tables
4.1 Configuration used for running the CDxbenchmark. . . 48 4.2 Size of binaries with different GCs . . . 50
57
Bibliography
[1] C. Lang, “Improved stack allocation using escape analysis in the KESO multi-JVM,” bachelor’s thesis, Friedrich-Alexander Universität Erlangen-Nürnberg, 2012.
[2] C. W. A. Wawersich, “Keso: Konstruktiver Speicherschutz für eingebettete Systeme.” Ph.D. dissertation, University of Erlangen-Nuremberg, 2009.
[3] B. Alpern, C. R. Attanasio, A. Cocchi, D. Lieber, S. Smith, T. Ngo, J. J. Barton, S. F. Hummel, J. C. Sheperd, and M. Mergen, “Implementing Jalapeño in Java,”
ACM SIGPLAN Notices, vol. 34, no. 10, pp. 314–324, 1999.
[4] D. Frampton, S. M. Blackburn, P. Cheng, R. J. Garner, D. Grove, J. E. B. Moss, and S. I. Salishev, “Demystifying magic: high-level low-level programming,”
in Proceedings of the 2009 ACM SIGPLAN/SIGOPS international conference on Virtual execution environments. ACM, 2009, pp. 81–90.
[5] S. M. Blackburn, P. Cheng, and K. S. McKinley, “Oil and water? High perfor-mance garbage collection in Java with MMTk,” in ICSE 2004, 26th International Conference on Software Engineering, Edinburgh, Scotland, May 23-28, 2004.
IEEE, May 2004.
[6] D. Simon and C. Cifuentes, “The squawk virtual machine: Java™ on the bare metal,” in Companion to the 20th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications. ACM, 2005, pp.
150–151.
[7] Sun Microsystems Inc., “Squawk VM source code,” https://svn.java.net/svn/
squawk⇠svn, 2004 – 2013, revision 973.
[8] F. Henderson, “Accurate garbage collection in an uncooperative environment,”
in ACM SIGPLAN Notices, vol. 38, no. 2 supplement. ACM, 2002, pp. 150–156.
[9] B. W. Kernighan, D. M. Ritchie, and P. Ejeklint, The C programming language.
Prentice-Hall Englewood Cliffs, 1988, vol. 2.
59
60 Bibliography
[10] M. Aiken, M. Fähndrich, C. Hawblitzel, G. Hunt, and J. Larus, “Deconstructing process isolation,” in Proceedings of the 2006 workshop on Memory system performance and correctness. ACM, 2006, pp. 1–10.
[11] A. Tim/Yellin Lindholm (Frank/Bracha, Gilad/Buckley, The Java Virtual Ma-chine Specification: Java SE 8 Edition. Prentice Hall, 2014.
[12] M. Stilkerich, I. Thomm, C. Wawersich, and W. Schröder-Preikschat, “Tailor-made JVMs for statically configured embedded systems,” Concurrency and Computation: Practice and Experience, vol. 24, no. 8, pp. 789–812, 2012.
[13] E. Gamma, R. Helm, C. Larman, R. Johnson, and J. Vlissides, Design Patterns:
Elements of Reusable Object-Oriented Software, ser. Addison-Wesley Professional Computing Series. Pearson Education, Limited, 2005.
[14] C. Erhardt and M. Stilkerich, “A Control-Flow-Sensitive Analysis and Optimiza-tion Framework for the KESO Multi-JVM,” 2011.