added zoltans suggestions

evaluation/octane-benchmark-read-only/results/octane_deopt.vsz

@@ -1,5 +1,5 @@
 # Veusz saved document (version 1.22)
-# Saved at 2015-07-23T07:04:39.489117
+# Saved at 2015-07-31T08:53:28.629968
 
 AddImportPath(u'/home/marcel/cloud/ETH/6thSemesterFS15/BachelorThesis/hs-comp/hotspot/evaluation/octane-benchmark-read-only/results')
 ImportFileCSV(u'results.csv', delimiter=';', linked=True)
@@ -18,7 +18,7 @@ Add('axis', name='y', autoadd=False)
 To('y')
 Set('label', u'number of deoptimizations')
 Set('min', 0.0)
-Set('max', 1950.0)
+Set('max', 2100.0)
 Set('direction', 'vertical')
 Set('Label/size', u'16pt')
 Set('TickLabels/size', u'14pt')

evaluation/specvm/onlyc2/warmup/all_warmup_variation_wo_i.vsz

@@ -1,5 +1,5 @@
 # Veusz saved document (version 1.22)
-# Saved at 2015-07-30T09:36:00.855468
+# Saved at 2015-07-31T15:09:23.759206
 
 AddImportPath(u'/home/marcel/cloud/ETH/6thSemesterFS15/BachelorThesis/hs-comp/hotspot/evaluation/specvm/onlyc2/warmup')
 ImportFileCSV(u'results_warmup.csv', delimiter=';', linked=True)

evaluation/specvm/warmup/others_warmup_deopt.vsz

@@ -1,5 +1,5 @@
 # Veusz saved document (version 1.22)
-# Saved at 2015-07-23T06:50:24.718682
+# Saved at 2015-07-31T08:54:24.687009
 
 AddImportPath(u'/home/marcel/cloud/ETH/6thSemesterFS15/BachelorThesis/hs-comp/hotspot/evaluation/specvm/warmup')
 ImportFileCSV(u'others_warmup.csv', delimiter=';', linked=True)
@@ -19,7 +19,7 @@ Add('axis', name='y', autoadd=False)
 To('y')
 Set('label', u'number of deoptimizations')
 Set('min', 0.0)
-Set('max', 1850.0)
+Set('max', 1900.0)
 Set('direction', 'vertical')
 Set('Label/size', u'16pt')
 Set('TickLabels/size', u'14pt')

report/bibliography.bib

@@ -91,8 +91,18 @@ @misc{code_intrinsics
 }
 @misc{intrinsics_talk,
   title={{Intrinsic Methods in HotSpot}},
-  author={Krystal Mo},
+  author={Krystal Mok},
   note={{Talk from GreenTeaJUG event}},
   year={2013},
-  howpublished = "\url{http://www.oracle.com/technetwork/java/javase/tech/3198-d1-150056.pdf}"
+  howpublished = "\url{http://www.slideshare.net/RednaxelaFX/green-teajug-hotspotintrinsics02232013}"
+}
+@article{georges2007statistically,
+  title={Statistically rigorous java performance evaluation},
+  author={Georges, Andy and Buytaert, Dries and Eeckhout, Lieven},
+  journal={ACM SIGPLAN Notices},
+  volume={42},
+  number={10},
+  pages={57--76},
+  year={2007},
+  publisher={ACM}
 }

report/conclusion.tex

@@ -1,12 +1,12 @@
 Modern Java Virtual Machines (JVM) like HotSpot gather profiling information about executed methods to improve the quality of the compiled code.
 This thesis presents several approaches to reuse profiling information, that have been dumped to disk in previous executions of the JVM.
 \\\\
-The expected advantage is a faster warmup of the Virtual Machine, because the JVM does not need to spend time profiling the code and can use cached profiles directly.
+The expected advantage is a faster warmup of the Java Virtual Machine, because the JVM does not need to spend time profiling the code and can use cached profiles directly.
 Furthermore, since the cached profiles originate from previous compilations, where extensive profiling already happened, compilations using these profiles produce more optimized code, which decreases the amount of deoptimizations.
 \\\\
-We show, using two benchmark suites, that cached profiles can indeed improve warmup performance and significantly lower the amount of deoptimizations.
-Therefore, we believe, that cached profiles are a valuable asset in scenarios where a fast JVM warmup is needed and performance fluctuations during tiered compilation want to be avoided.
+We show, using two benchmark suites, that cached profiles can indeed improve warmup performance and significantly lower the amount of deoptimizations as well as reduce the time spent in the JIT compilers.
+Therefore, we believe, that cached profiles are a valuable asset in scenarios where a fast JVM warmup is needed and performance fluctuations during tiered compilation are desired to be avoided.
 \\\\
-In addition, we tested individual benchmarks for the impact of cached profiles on the load of the compile queue, the amount and type of compilations, and the time spent in the compilers. The results show, that neither of them gives one-to-one correspondence between the examined factor and performance. However, the results provide indications, where the performance increase or decrease could come from.
+In addition, we evaluated the performance of our approach with individual benchmarks for the impact of cached profiles on the load of the compile queue and the amount and type of compilations. The results show, that neither of them gives one-to-one correspondence between the examined factor and performance. However, the results provide indications, where the performance increase or decrease could come from.
 \\\\
-The functionality is implemented in the HotSpot JVM (openJDK9). It provides the user of the JVM several choices on how to use the system and allows fine-grained selection of the cached methods.
+The functionality is implemented in the HotSpot JVM (OpenJDK9). It provides the user of the JVM several choices on how to use the system.

report/implementation.tex

@@ -80,7 +80,7 @@ \section{Creating cached profiles}
 \section{Initializing cached profiles}
 \label{s:initializingprofiles}
 The information dumped in step \ref{s:creatingprofiles} can now be used in a next run of that particular program.
-To specify that profiles are available, we introduce a new compiler flag \texttt{-XX:+CacheProfiles} that enables the use of previously generated profiles. By default, it reads from a file called \textit{cached\_profiles.dat} but a different file can be specified using \texttt{-XX:CacheProfilesFile=other\_file.dat}.
+To specify that profiles are available, we introduce a new compiler flag \texttt{-XX:+CacheProfiles} that enables the use of previously generated profiles. By default, it reads from a file called \textit{cached\_profiles.dat} but a different file can be specified using:\\ \texttt{-XX:CacheProfilesFile=other\_file.dat}.
 \\\\
 Before any cached profiles can be used the virtual machine has to parse that file and organize the profiles and compile information in a data structure. This data structure is completely kept in memory during the whole execution of the JVM to avoid multiple disk accesses.
 The parsing process is invoked during boot up of the JVM, directly after the compileBroker gets initialized. This happens before any methods are executed and blocks the main thread of the JVM until finished.

report/improvements.tex

@@ -2,7 +2,7 @@
 \begin{itemize}
   \item There is a time overhead for parsing the cached profiles file when the JVM boots up. This could be lowered by finding more compact ways of storing profiles to disk or storing the cached profiles in main memory.
   \item The data structure of the cached profiles is a simple C heap array. The worst case lookup is $O(n)$ with $n$ being the number of cached method compilations. By using a more advanced tree-like data structure we could improve this to $O(log(n))$.
-  \item Additionally, all method compilations get dumped and stored. The system could be extended in a way, that only the last compilation record of a method is kept in the file. On cost of additional memory overhead, this can decrease the size of the cached profile file and result in a lower parsing time.
+  \item Additionally, all method compilations get dumped and stored. The system could be extended in a way that only the last compilation record of a method is kept in the file. On the cost of additional memory overhead, this can decrease the size of the cached profile file and result in a lower parsing time.
   \item Currently, only the profiles of a single run are used. A possible improvement is to use multiple executions for gathering the cached profiles and come up with ways to merge the profiling information. More complete profiles can be achieved, which could further reduce the number of deoptimizations.
   \item In addition to merging multiple profiles we also though about the possibility to modify the cached profile. That would allow the JVM user to manually improve profiling information by using his knowledge of the method execution which might not be available to the compiler.
   \item There are several more interesting benchmarks that could be executed. For example, one could try optimizing the benchmarks by only selecting a subset of all methods to be cached. Or a more detailed investigation on different multi core systems, to get more insight which threads are limiting performance, could be executed.