JATO: Native Code Atomicity for Java

2012 ◽  
pp. 2-17 ◽  
Author(s):  
Siliang Li ◽  
Yu David Liu ◽  
Gang Tan
Keyword(s):  
Native Code

Modeling and generating native code for cross-platform mobile applications using DSL

2016 ◽  
Vol 23 (3) ◽  
pp. 445-458 ◽  
Author(s):  
Mohamed Lachgar ◽  
Abdelmounaïm Abdali
Keyword(s):  
Mobile Applications ◽  
Cross Platform ◽  
Native Code

Protecting Android Apps from Repackaging Using Native Code

2020 ◽  
pp. 189-204
Author(s):  
Simon Tanner ◽  
Ilian Vogels ◽  
Roger Wattenhofer
Keyword(s):  
Android Apps ◽  
Native Code

scholarly journals MATLAB-Like Scripting of Java Scientific Libraries in ScalaLab

2014 ◽  
Vol 22 (3) ◽  
pp. 187-199
Author(s):  
Stergios Papadimitriou ◽  
Seferina Mavroudi ◽  
Kostas Theofilatos ◽  
Spiridon Likothanasis
Keyword(s):  
Software Development ◽  
Scientific Computation ◽  
The Core ◽  
Java Bytecode ◽  
Front End ◽  
Average Scientist ◽  
Native Code ◽  
Scientific Libraries

Although there are a lot of robust and effective scientific libraries in Java, the utilization of these libraries in pure Java is difficult and cumbersome, especially for the average scientist that does not expertise in software development. We illustrate that ScalaLab presents an easier and productive MATLAB like front end. Also, the main strengths and weaknesses of the core Java libraries of ScalaLab are elaborated. Since performance is of paramount importance for scientific computation, the article discusses extensively performance aspects of the ScalaLab environment. Also, Java bytecode performance is compared to native code.

Identifying Java Calls in Native Code via Binary Scanning (artifact)

2020 ◽  
Author(s):  
George Fourtounis ◽  
Leonidas Triantafyllou ◽  
Yannis Smaragdakis
Keyword(s):  
Native Code

scholarly journals ScalaLab and GroovyLab: Comparing Scala and Groovy for Scientific Computing

2015 ◽  
Vol 2015 ◽  
pp. 1-13
Author(s):  
Stergios Papadimitriou ◽  
Kirsten Schwark ◽  
Seferina Mavroudi ◽  
Kostas Theofilatos ◽  
Spiridon Likothanasis
Keyword(s):  
Programming Language ◽  
User Interfaces ◽  
High Performance ◽  
Scientific Computing ◽  
Point Of View ◽  
Java Virtual Machine ◽  
Programming Environment ◽  
Fast Pace ◽  
Native Code ◽  
Performance Computing

ScalaLab and GroovyLab are both MATLAB-like environments for the Java Virtual Machine. ScalaLab is based on the Scala programming language and GroovyLab is based on the Groovy programming language. They present similar user interfaces and functionality to the user. They also share the same set of Java scientific libraries and of native code libraries. From the programmer's point of view though, they have significant differences. This paper compares some aspects of the two environments and highlights some of the strengths and weaknesses of Scala versus Groovy for scientific computing. The discussion also examines some aspects of the dilemma of using dynamic typing versus static typing for scientific programming. The performance of the Java platform is continuously improved at a fast pace. Today Java can effectively support demanding high-performance computing and scales well on multicore platforms. Thus, both systems can challenge the performance of the traditional C/C++/Fortran scientific code with an easier to use and more productive programming environment.

OCaml-Java: The Java Virtual Machine as the target of an OCaml compiler

2016 ◽  
Vol 26 ◽  
Author(s):  
XAVIER CLERC
Keyword(s):  
Virtual Machine ◽  
Java Virtual Machine ◽  
Garbage Collector ◽  
Main Design ◽  
Java Bytecode ◽  
Multiple Cores ◽  
Memory Footprint ◽  
Native Code ◽  
Technological Challenge

AbstractThis article presents how the compiler from the OCaml-Java project generates Java bytecode from OCaml sources. Targeting the Java Virtual Machine (JVM) is a technological challenge, but gives access to a platform where OCaml can leverage multiple cores and access numerous libraries. We present the main design choices regarding the runtime and the various optimizations performed by the compiler that are crucial to get decent performance on a JVM. The challenge is indeed not only to generate bytecode but to generate efficient bytecode, and to provide a runtime library whose memory footprint does not impede the efficiency of the garbage collector. We focus on the strategies that differ from the original OCaml compiler, as the constraints are quite different on the JVM when compared to native code. The level of performance reached by the OCaml-Java compiler is assessed through benchmarks, comparing with both the original OCaml implementation and the Scala language.

scholarly journals On the implementation ofGNU Prolog

2011 ◽  
Vol 12 (1-2) ◽  
pp. 253-282 ◽  
Author(s):  
DANIEL DIAZ ◽  
SALVADOR ABREU ◽  
PHILIPPE CODOGNET
Keyword(s):  
High Performance ◽  
System Organization ◽  
General Purpose ◽  
Finite Domain ◽  
Organization Performance ◽  
Constraint Solver ◽  
Native Code

AbstractGNU Prologis a general-purpose implementation of the Prolog language, which distinguishes itself from most other systems by being, above all else, a native-code compiler which produces stand-alone executables which do not rely on any bytecode emulator or meta-interpreter. Other aspects which stand out include the explicit organization of the Prolog system as a multipass compiler, where intermediate representations are materialized, in Unix compiler tradition.GNU Prologalso includes an extensible and high-performance finite-domain constraint solver, integrated with the Prolog language but implemented using independent lower-level mechanisms. This paper discusses the main issues involved in designing and implementingGNU Prolog: requirements, system organization, performance, and portability issues as well as its position with respect to other Prolog system implementations and the ISO standardization initiative.

Sign in / Sign up

Export Citation Format

Share Document