Understanding the performance of the Java operating system JX using visualization techniques

Abstract

In the JX project 1 we build a complete operating system using the type-safe, object-oriented language Java. One of the major challenges is achieving a performance that is competitive to mainstream operating systems, such as Linux or Solaris. It is in the nature of our microkernel-based system, that most time is spent executing Java code. Achieving a good performance therefore requires an optimizing bytecode-to-nativecode translator and instrumentation/visualization tools to locate performance problems. In this paper we concentrate on the second requirement. We instrumented the microkernel and the bytecode-to-nativecode translator to get information about nearly every aspect of the systems behavior. The gathered data can be visualized to show CPU time consumption of methods, thread scheduling, object allocation behavior, and object ages. Time related information.To improve the code, it is necessary for the programmer to identify the most time-consuming parts of a program. These often indicate poor code or bottlenecks and are the parts of the code that benefit most from optimizations. We have two possibilities to identify such parts: (1) method timing and (2) sampling.Method timing. For method timing we instrumented our bytecodeto-nativecode translator to insert code that measures the execution times of methods. The elapsed time during a method is recorded using the time stamp counter (TSC) of the Pentium processor family. The result is totalized for each invocation pair consisting of caller and callee method. The sum is saved together with the number of invocations and the caller and callee address in a data structure per thread. Especially in nested methods the measurement overhead falsifies the result. To get more accurate results, we accumulate the quantified drift by identifying the needed extra cycles. The results can be visualized using a call graph display, or a time diagram, where the time consumed by a method is proportional to the size of a box. Furthermore the execution of extra code during the measurement has noticeable impact on the memory access, the caches, the buffers, and the branch prediction of the processor.Sampling. Sampling is used to find hotspots in the system, but with almost no measurement overhead. While timing measures the exact execution times of methods, sampling can only produce a statistical view of the system. The timer interrupt service routine (ISR) logs the instruction pointer of the interrupted instruction. The distribution of the instruction pointers indicates where the program spends most of its time.Event tracing. JX allows Java components to log component-specific events to an kernel internal event log. The events can be specified by using a system interface. Additionally our bytecode translator may insert calls to the log system to record specific method calls. Time stamps and event numbers are continuously stored in main memory. The microkernel also uses this logging mechanism to log some internal events. For example, the scheduling behavior of the system can be logged a...

Functional Modelling of Operating Systems

“…Speaking of virtual machines in the world of operating systems, it is worth mentioning JX, [25] an operating system written in Java, which runs on an extended Java Virtual Machine. Most of the employed extensions cover functions those required for making certain operating system services accessible to applications.…”

Intercessão em Tempo de Implantação – uma Abordagem Reflexiva para a Plataforma J2EE™ –

“…1 De fato, o termo mais usado na literatura para designar reflexão comportamental é interceptação, porém sua semântica enfatiza bloqueio, obstáculo. Por essa razão, adotou-se o termo intercessão [5] [20], cujo significado -interceder, intermediar -é mais apropriado. A plataforma J2EE já contém implicitamente características de introspecção (reflexão estrutural), fundamentadas sobre as APIs de Reflexão Java, que inclusive são utilizadas por ferramentas de desenvolvimento para levantar informações estruturais (métodos, atributos) dos componentes [12].…”

“…Contudo, a reflexão comportamental, que permite a intercessão de propósito geral a métodos, não é especificada diretamente pelo padrão Java. Essa é uma das principais motivações de estudos que propõem o acréscimo dessa característica ao padrão Java, como o metaXa [5], o OpenJava [20] e o Guaraná [10] -com o objetivo de permitir que sistemas baseados em Java se beneficiem de um mecanismo de reflexão unificado. Em síntese, essas arquiteturas reflexivas fundamentam-se em uma das seguintes abordagens:…”

“…ex., gerando conflitos com as atribuições do container). Por fim, soluções corporativas baseadas em componentes são intrinsecamente de menor granularidade que as soluções visadas pelas abordagens [5], [20] e [10]. Isto altera o enfoque objetivado pela aplicação: maior granularidade, menor modularidade, solução mais ad hoc; menor granularidade, maior modularidade, solução de maior abrangência, característica das soluções servidoras corporativas.…”

“…No que se refere à Plataforma Java, tais capacidades reflexivas integrais não estão completamente especificadas, sendo esse o tema de estudo de várias abordagens: [10], [20] e [5]. No entanto, essas propostas ou propõem uma nova perspectiva para o padrão Java, ou se baseiam em práticas nem sempre acessíveis na plataforma J2EE -o que pode vir a comprometer as vantagens corporativas e de ambiente oferecidas pela plataforma J2EE.…”