Frequently Asked Questions - General

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.