Carsten Otto, Marc Brockschmidt, Christian von Essen et al. · DROPS (Schloss Dagstuhl – Leibniz Center for Informatics) · 2010
We present an automated approach to prove termination of Java Bytecode (JBC) programs by automatically transforming them to term rewrite systems (TRSs). In this way, the numerous techniques and tools developed for TRS termination can now be used for imperative object-oriented languages like Java, which can be compiled into JBC.
Cited by 71Open access
Ozimek, Konrad · Jagiellonian University Repository (Jagiellonian University)
Kontynuatcje są konstrukcją programistyczną często występującą w funkcyjnych językach programowania, które w połączeniu z odpowiednimi operatorami pozwalają programiście wyrażać dowolny przepływ sterowania.Ich implementacja jest problematyczna jeśli program działa na maszynie która nie daje mu bezpośredniego dostępu do części jej stanu, na przykład stosu wykonania.Taką maszyną jest na przykład wirtualna maszyna Javy.W naszej pracy przedstawiamy jedną z form kontynuacji, delimited continuations, opisujemy niektóre z zestawów operatorów działających na nich, oraz podajemy implementację jednego z nich dla języka Java:1. reset, ograniczący zakres kontynuacji,2. shift, przechwytujący kontynuację ograniczoną przez reset.Nasza implementacja opiera się na modyfikacji kodu pośredniego wykonywanego na wirtualnej maszynie Javy.
Cited by 0
Christoph Bockisch, Deniz Eren, S. Lehmann et al. · 2024
Mutation testing is an approach to checking the robustness of test suites. The program code is slightly changed by mutations to inject bugs. A test suite is robust enough if it finds such bugs. Mutation testing tools typically integrate sets of mutation operators such as, for example, swapping arithmetic operators; modern tools typically work with compiled code such as Java bytecode. The mutations must be defined in such a way that the mutated program can still be loaded and executed. The results of mutation tests depend directly on the possible mutations. More advanced mutations and even domain-specific mutations can pose another challenge to the test suite. Since the classical, non-model-based mutation testing tools do not support the specification of advanced mutation operators well, we propose a model-driven approach where mutations of Java bytecode can be flexibly defined by model transformation. Our approach also provides advanced mutation operators for modifying object-oriented structures, Java-specific properties and API method calls, making it the only mutation testing tool for Java bytecode that supports such mutations. To further improve the effectiveness of mutation testing, mutants are generated only for bytecode that is covered by tests. Our approach is implemented in the MMT tool. It has been evaluated against non-model-based mutation testing tools for its ability to generate mutants close to real bugs. The experiments make use of Defects4J, a well-established collection of real-world Java projects with reproducible bugs.
Cited by 0Open access
Étienne Payet, Fausto Spoto · HAL (Le Centre pour la Communication Scientifique Directe) · 2007
Cited by 0Open access
Michel Durante Zimmermann · 2004
Cited by 0
Christoph Bockisch, Gabriele Taentzer, Daniel Neufeld · 2023
Mutation testing is an approach to check the robustness of test suites. The program code is slightly changed by mutations to inject errors. A test suite is robust enough if it finds such errors. Tools for mutation testing usually integrate sets of mutation operators such as, for example, swapping arithmetic operators; modern tools typically work with compiled code such as Java bytecode. In this case, the mutations must be defined in such a way that the mutated program still can be loaded and executed. The results of mutation tests depend directly on the possible mutations. More advanced mutations and even domain-specific mutations can pose another challenge to the test suite. Since extending the classical approaches to more complex mutations is not well supported and is difficult, we propose a model-driven approach where mutations of Java bytecode can be flexibly defined by model transformation. The corresponding tool called MMT has been extended with advanced mutation operators for modifying object-oriented structures, Java-specific properties and method calls of APIs, making it the only mutation testing tool for Java bytecode that supports such mutations.
Cited by 3
Damiano Zanardini · 2006
This work presents a program analyzer for checking Abstract Non-Interference in a fragment of Java bytecode. Abstract Non-Interference is an information flow property which is weaker and more general than standard Non-Interference, since it can allow some selected parts of secret information to flow into the public part of a program. The motivation for such a weakening is that some flows are indeed useful in real-life applications. The amount of allowed flows is encoded into abstract domains, which characterize the degree of precision of a potential attacker in observing data; flows are forbidden as long as they can be observed and exploited by attackers. Abstract values describe possible values of programs in different executions. Basic features of Java bytecode are considered; advanced topics, such as method calls, objects and exceptions, are also discussed. A program is said to be secure if analysis computes a state which does not contain private information in public places; information flows can exist only as long as the attacker has not enough observational power to see and exploit them.
Cited by 5
Chukri Soueidi, Marius Monnier, Ylìès Falcone · International Journal on Software Tools for Technology Transfer · 2023
Cited by 9Open access
Weifeng Xu, Tao Ding, Hanlin Wang et al. · 2013
Search-based test generation can automatically produce a large volume of test inputs. However, it is difficult to define the test oracle for each of the test inputs. This paper presents a mining approach to building a decision tree model according to the test inputs generated from Java bytecode. It converts Java bytecode into the Jimple representation, extracts predicates from the control flow graph of the Jimple code, and uses these predicates as attributes for organizing training data to build a decision tree. Our case studies show that the mining approach generated accurate behavioral models and that test oracles derived from these models were able to kill 94.67% of the mutants with injected faults.
Cited by 8
Dávid Tengeri, Ferenc Horváth, Árpád Beszédes et al. · SZTE Publicatio Repozitórium (University of Szeged) · 2016
Code coverage measurement is an important element in white-box testing, both in industrial practice and academic research. Other related areas are highly dependent on code coverage as well, including test case generation, test prioritization, fault localization, and others. Inaccuracies of a code coverage tool sometimes do not matter that much but in certain situations they can lead to serious confusion. For Java, the prevalent approach to code coverage measurement is to use bytecode instrumentation due to its various benefits over source code instrumentation. However, if the results are to be mapped back to source code this may lead to inaccuracies due to the differences between the two program representations. In this paper, we systematically investigate the amount of differences in the results of these two Java code coverage approaches, enumerate the possible reasons and discuss the implications on various applications. For this purpose, we relied on two widely used tools to represent the two approaches and a set of benchmark programs from the open source domain.
Cited by 16Open access
Ahmet Çelik, Pengyu Nie, Christopher J. Rossbach et al. · Proceedings of the ACM on Programming Languages · 2019
We present the design and implementation of GVM, the first system for executing Java bytecode entirely on GPUs. GVM is ideal for applications that execute a large number of short-living tasks, which share a significant fraction of their codebase and have similar execution time. GVM uses novel algorithms, scheduling, and data layout techniques to adapt to the massively parallel programming and execution model of GPUs. We apply GVM to generate and execute tests for Java projects. First, we implement a sequence-based test generation on top of GVM and design novel algorithms to avoid redundant test sequences. Second, we use GVM to execute randomly generated test cases. We evaluate GVM by comparing it with two existing Java bytecode interpreters (Oracle JVM and Java Pathfinder), as well as with the Oracle JVM with just-in-time (JIT) compiler, which has been engineered and optimized for over twenty years. Our evaluation shows that sequence-based test generation on GVM outperforms both Java Pathfinder and Oracle JVM interpreter. Additionally, our results show that GVM performs as well as running our parallel sequence-based test generation algorithm using JVM with JIT with many CPU threads. Furthermore, our evaluation on several classes from open-source projects shows that executing randomly generated tests on GVM outperforms sequential execution on JVM interpreter and JVM with JIT.
Cited by 4Open access
Richard L. Apodaca · Front Matter · 2007
Some time ago, a Depth-First article discussed some methods for compiling C to Java bytecode. Many factors make this approach attractive compared to the JNI approach. Some of them include security, portability, and use within applets. Unfortunately, none of the approaches discussed in the earlier article seemed particularly general.
Cited by 2Open access
Christian Collberg · 2005
BCEL (formerly JavaClass) allows you to load a class, iterate through the methods and fields, change methods, add new methods and fields, etc. BCEL also makes it easy to create new classes from scratch. [2] 620 —Fall 2005 — 2 Getting started To open a class file for editing you do the following: org.apache.bcel.classfile.ClassParser p = new org.apache.bcel.classfile.ClassParser(classFile); org.apache.bcel.classfile.JavaClass jc = p.parse() org.apache.bcel.generic.ClassGen cg = new org.apache.bcel.generic.ClassGen(jc); org.apache.bcel.generic.ConstantPoolGen cp = new org.apache.bcel.generic.ConstantPoolGen( jc.getConstantPool()); [3] 620 —Fall 2005 — 2 Getting started... A org.apache.bcel.classfile.JavaClass-object represents the parsed class file. You can query this object to get any information you need about the class, for example its methods, fields, code, super-class, etc. A org.apache.bcel.generic.ClassGen-object represents a class that can be edited. You can add methods and fields, you can modify existing methods, etc. A org.apache.bcel.generic.ConstantPoolGen-object represents a constant pool to which new constants can be added. [4] 620 —Fall 2005 — 2 Finishing up When you are finished editing the class you must close and save it to the new class file: org.apache.bcel.classfile.JavaClass jc1 = cg.getJavaClass(); jc1.setConstantPool(cp.getFinalConstantPool()); jc1.dump(classFile1); [5] 620 —Fall 2005 — 2 Editing a Method org.apache.bcel.classfile.Method represents a method that has been read from a class file. org.apache.bcel.generic.MethodGen is the BCEL class that represents a method being edited: org.apache.bcel.generic.ConstantPoolGen cp =...; org.apache.bcel.generic.ClassGen cg =...; org.apache.bcel.classfile.Method method = cg.containsMethod(methodName, methodSignature); org.apache.bcel.generic.MethodGen mg = new org.apache.bcel.generic.MethodGen(method,cname,cp);
Cited by 0
Lucas C. Cordeiro, Pascal Kesseli, Daniel Kroening et al. · Lecture notes in computer science · 2018
We present a bounded model checking tool for verifying Java bytecode, which is built on top of the CPROVER framework, named Java Bounded Model Checker (JBMC). JBMC processes Java bytecode together with a model of the standard Java libraries and checks a set of desired properties. Experimental results show that JBMC can correctly verify a set of Java benchmarks from the literature and that it is competitive with two state-of-the-art Java verifiers.
Cited by 68Open access
Masci, Paolo · Electronic Theses and Dissertations Repository (University of Pisa) · 2003
La tecnologia Java Card costituisce il punto di contatto tra il linguaggio di programmazione Java e l’ambiente operativo di sistemi con un numero limitato di risorse. Java è un linguaggio interpretato: il codice assemblato viene eseguito su una macchina virtuale, la Java Virtual Machine (JVM), che garantisce l’indipendenza del codice dalla particolare piattaforma hardware/software. La JVM gioca inoltre un ruolo centrale per quanto riguarda la sicurezza e la correttezza del codice eseguito: la sicurezza è legata a meccanismi che controllano i diritti di accesso a informazioni e funzionalità, la correttezza garantisce invece che i meccanismi di sicurezza non vengano by-passati. Il “verificatore” è il modulo della JVM che analizza la correttezza del codice: la tecnologia corrente non consente l’implementazione di un verificatore “standard” direttamente on-card perché il processo di verifica richiede in genere un numero elevato di risorse. In questa tesi viene proposto un verificatore che ottimizza l’utilizzo delle risorse attraverso una analisi del grafo di flusso del codice: l’idea di base è di scomporre il codice in blocchi indipendenti e di rendere dinamica l’allocazione delle risorse applicando l’algoritmo di verifica ad ogni blocco. Le risorse da allocare sono solo quelle necessarie alla verifica di un sotto-insieme di istruzioni: la complessità del processo di verifica diminuisce e la realizzazione di un verificatore on-card diventa un obiettivo raggiungibile. E’ stato inoltre sviluppato un prototipo a partire dal codice di un verificatore open-source.
Cited by 0Open access
M. Watheq El‐Kharashi, F. El-Guibaly, K.F. Li · 2001
This paper presents a novel processor architecture for executing Java bytecodes in hardware. Our processor is based on an instruction folding algorithm implemented with Tomasulo's scheduling algorithm. The architecture also provides dual processing capability to execute Java bytecodes as well as other binaries. This approach improves Java execution without sacrificing the generality of the processor.
Cited by 1
Stephen N. Freund, John C. Mitchell · 2003
The Java Virtual Machine executes bytecode programs that may have been sent from other, possibly untrusted, locations on the network. Since the transmitted code may be written by a malicious party or corrupted during network transmission, the Java Virtual Machine contains a bytecode verifier to check the code for type errors before it is run. As illustrated by reported attacks on Java run-time systems, the verifier is essential for system security. However, no formal specification of the bytecode verifier exists in the Java Virtual Machine Specification published by Sun. In this paper, we develop such a specification in the form of a type system for a subset of the bytecode language. The subset includes classes, interfaces, constructors, methods, exceptions, and bytecode subroutines. We also present a type checking algorithm and prototype bytecode verifier implementation, and we conclude by discussing other applications of this work. For example, we show how to extend our formal system to check other program properties, such as the correct use of object locks.
Cited by 0
Yang Zhang, Shuai Shao, Huan Liu et al. · IEEE Access · 2019
Developers of parallel programming are faced with choices of using various Java locks. Choosing the best lock is a challenging task because a multithreaded application implemented using different locks may end up with uncertain performance. There is a strong need for automated tool support that helps Java programmers choose the best lock for each specific application. This paper presents an automated transformation approach to convert an implementation using a synchronized lock to a ReentrantLock or a ReentrantReadWriteLock at the bytecode level. For the ReentrantLock, our approach runs analysis for global monitors using the visitor pattern in the Joeq compiler. For the ReentrantReadWriteLock, a read or write lock is chosen after a side-effect analysis. Then, the proposed system validates the consistency of the analysis results to ensure a correct sequence of lock usage. Finally, lock operations and related thread communication operations are transformed into a ReentrantLock or a ReentrantReadWriteLock using a bytecode transformation framework Javassist. We validate our approach on several benchmarks including RBTree, PC, SPECjbb2005, and HSQLDB. The experimental results show that the proposed automated transformation approach can transform these benchmarks successfully in a timely fashion.
Cited by 15Open access
Andreas Kunert · 2008
Since the very early beginnings of parallel discrete event-driven simulation (PDES) research, numerous general-purpose PDES frameworks have been imple-mented. These frameworks can be roughly classi-fied by the utilized modelling view (process-oriented vs. event-oriented), kind of parallelism (conservative-parallel, optimistic-parallel), and implementation lan-guage. Since the main motivation of parallel simulation is the acceleration of single simulation runs, most PDES frameworks have been written in rather low-level lan-guages using the event-oriented modelling view. How-ever, the drawbacks of this approach are modelling re-strictions to the user and the impossibility to use con-cepts of higher-level programming languages or to in-teroperate directly with programs written in such lan-guages. In this paper, we review different approaches to im-plement general-purpose simulation processes in Java and discuss the appropriateness of them regarding optimistic-parallel simulations. Afterwards, we present our current prototypical imple-mentation of an optimistic-parallel simulation frame-work in Java providing simulation processes based on a bytecode rewriting approach.
Cited by 0
Pedersen Jan B aelig kgaard, K Brian · IOS Press eBooks · 2009
This paper describes an implementation of resumable and mobile processes for a new process-oriented language called ProcessJ. ProcessJ is based on CSP and the π-calculus; it is structurally very close to occam-π, but the syntax is much closer to the imperative part of Java (with new constructs added for process orientation). One of the targets of ProcessJ is Java bytecode to be executed on the Java Virtual Machine (JVM), and in this paper we describe how to implement the process mobility features of ProcessJ with respect to the Java Virtual Machine. We show how to add functionality to support resumability (and process mobility) by a combination of code rewriting (adding extra code to the generated Java target code), as well as bytecode rewriting.
Cited by 0