Frequently Asked Questions

Before transferring the binary, you must switch to binary transfer mode.

DO NOT use the ASCII transfer mode. This will result in broken JamaicaVM binaries that will lead to segmentation faults on execution.

If you do not have a method to determine the maximum memory allocated value, but you believe you have sufficient available memory, the garbage collector can be configured with a minimal initial heapsize, and a maximum heapsize value to enable dynamically growing the heap during program execution. Because the garbage collector is work-based, incremental, and preemptible.

If you are using dynamically loaded code, such as through reflection, that was not accessed during your memory analysis run, the maximum memory allocated value may be lower than your actual usage. You must ensure that you have configured sufficient memory to avoid memory exhaustion exceptions at runtime. You can determine the new maximum allocated memory value by running with the -analyze option. A manual alternative is to use the numBlocks command to learn the number of blocks needed per class, and do the multiplication and addition based on your knowledge of the number of instantiations in your code.

JamaicaVM currently supports dynamic loading of jar files and classes at runtime, with the exception of programs that are built with the -closed option. All dynamically loaded code is interpreted by the JamaicaVM bytecode interpreter. Interpreted code and fully compiled code is intermingled transparently.

JamaicaVM does not use a Just-in-time compiler as this introduces non-deterministic issues. There are two possible methods to create behavior similar to dynamic loading of fully compiled code currently:

  • Use a multi-processed approach. Use the Jamaica Builder to compile the new JAR file into a separate executable. Load the executable at runtime as a separate process and use interprocess communication mechanisms (e.g. shared memory, named pipes, msg queues, etc.)

  • Use the Jamaica Builder as part of your distribution process. Provided you have a mechanism to deploy new binaries to your deployed systems, run the Jamaica Builder with the new JAR files added to the list of included JAR files. To ensure that the new JAR files are compiled, use one of the following approaches:

    • Create a profile of the program with either the original version or a version that includes the new JAR file. Run Jamaica Builder with the newly generated profile to obtain the desired percent compiled of all the code including the new JAR.

    • Manually create an additional profile file that forces the methods you designate in the new JAR file to be compiled. Add the profile to the profile list given to Jamaica Builder.

Jamaica Builder uses a temporary directory to store intermediate files to reduce the build time. The intermediate files are rebuilt if the JAR or class file is newer than the intermediate file. To force a rebuild delete the intermediate files. The intermediate files are found in a subdirectory called “tmp” by default, but can be renamed with the -tmpdir switch.

No, you do not have to use Jamaicac. You can use any compiler that generates valid Java bytecodes. aicas ships Jamaicac with the toolchain as a convenience for developers.

Yes. The JamaicaVM Eclipse plugin is compatible with most Eclipse derivative IDEs. All of the JamaicaVM tools can be run from command line, output to stdout and can be integrated with any IDE that supports launching external tools.

This is a complete list of the tools in the JamaicaVM toolchain:

  • Jamaicac – Java language source code compiler

  • Jamaicah - for generating C header files that contain the function prototypes for all native methods in a given class

  • Jamaica Builder – the Java bytecode compiler

  • JamaicaTrace – thread visualization tool

  • Jamaica Numblocks – determines number of blocks to represent a given class

  • Eclipse Plugin – manages Jamaica projects

  • Prebuilt JamaicaVM binaries for the host system

The JamaicaVM User Manual can be found in the jamaica/doc directory where you installed your toolchain. For Windows, the default is C:\Program Files (x86) directory. It is also available on our company website in the Reference Material section.

The runtime class library API documentation can also be found in the Reference Material section.

Yes. JamaicaVM can be run on the target as standalone JVM interpreter. Refer to the Getting Started

section and chapter 12 The Jamaica Virtual Machine in the JamiacaVM User Manual for detailed information.


There are several possible runtime configurations for JamaicaVM providing the developer a lot of flexibility. These are:

  • Running in a purely interpreted mode. The prebuilt binaries provided in your platform support package for your specific target are ready to run on your target interpreting all bytecodes.


  • Compiling a set of JAR files and class files with the JamaicaVM runtime to create an extended JamaicaVM binary. The resulting binary behaves identically to the JamaicaVM with the addition that all precompiled JAR files and class files referenced by the program at runtime are executed as the target CPU's machine instructions, bypassing the JamaicaVM interpreter.


  • Compiling a set of JAR files, class files and the main class for the program into a complete executable, where the executable is still able to dynamically load classes are runtime.


  • Compiling a set of JAR files, class files and the main class for the program into a complete “closed” executable, where the executable does not dynamically load any classes at runtime.


The JamaicaVM toolchain is installed on a Windows or Linux host development system, not your target system. The JamaicaVM toolchain is used to build executables to be run on your target system.

Yes. The profile is logged in human readable text. The format is described in section 5.3 of the JamaicaVM User Manual.

You can use the “microprofile” feature of JamaicaVM Builder profiling. Refer to sections 5.1.4 and 5.2.2 in the JamaicaVM User Manual for more information.

Use the syntax -useProfile+=<filename>.

Use the -useProfile switch to include the profile you generated using the -profile switch. Refer to section 13.2.4 in the JamaicaVM User Manual for more information.

The -profile switch can be used with JamaicaVM Builder to build your program with profiling enabled. Refer to section 13.2.4 in the JamaicaVM User Manual for more information.

You can also use the prebuilt binary jamaicavmp to create a profile with your program. Refer to section 12.2.3 in the JamaicaVM User Manual.

Start JamaicaVM on the target using the following property


To dump a profile remotely call jamaica_remoteprofile.

$JAMAICA/bin/jamaica_remoteprofile <hostname> <port>

The JamaicaVM Builder is shipped with -XexcludeLongerThan=2500. This means that only methods with a bytecode count less than 2500 are candidates for compilation by the JamaicaVM Builder. This setting was needed historically for early toolchains that had size limitations. It can safely be increased to a large number such as 99999 with current toolchains.

The option -verbose=3 will output a log of all compiled classes.

The -profile switch informs JamaicaVM Builder to include the profiling code in the built executable. The performance of the resulting executable is approximately 2x to 3x slower due to the profiling code overhead. We recommend not to use this switch when building production code.

The JamaicaVM Builder is shipped with a default profile to compile the runtime class library, rt.jar for a preconfigured “average” use case. The jamiaca.conf file sets the percentageCompiled value to 10%. None of your program code is compiled with the default configuration. All of your program code is stored in a compressed bytecode format and interpreted at runtime.

We strongly recommend creating a profile for your program and supplying the profile to JamaicaVM Builder to optimize your program's performance.

The JamaicaVM interpreter will execute all Java bytecodes correctly. The performance is expected to be 25x to 35x slower than Java bytecodes compiled by the JamaicaVM Builder.

Yes. Veriflux is sound, which means that for every issues it checks for, all possible violations are identified in your code. If no violations for a particular issue are reported in the code that is analyzed, then issue is not present in the code.

Veriflux finds runtime exceptions, deadlocks, race conditions, and RTSJ memory area violations.

Please generate and forward the following:

  • A full stack trace of the error, if any, generated.

  • The full log file of the jamaicabuilder output from a clean build, with -verbose=3.

  • If you have a JamaicaTrace license, please run JamaicaTrace and save the log of a typical run,

  • Generate a profile using the -profile with Jamaica Builder or the prebuilt jamaicavmp binary of a typical run. Use the -Djamaica.profile_groups=all to collect all available profiling information for your platform. Forward the log file.

  • Generate a memory analysis log using the -analyze with Jamaica Builder of a typical run. Foward the log file.

  • If possible, forward any related source code. Note: Aicas is willing to sign NDA's to protect customer IP for support purposes.

  • If possible, forward an example of the problem with as minimal code as possible.

  • Provide as much explanation as possible about how the problem is generated or occurs.

  • Forward your support request to Please reference your company and any other relevant contact information.