Java Considerations

The data collection thread is run at a higher priority than all the other threads. The reason for this is that we don't want to lose any data, since that might require repositioning the panning motor and waiting for the scanning mirror to return to the point where the last good data was received.

Since Java is object-oriented and manages all object-memory in the JVM, a strong effort was made to allocate all the necessary objects prior to data collection so that the Java garbage collector would not run during data collection. We have had success here, it is noticeable when the collector runs, and we do not experience any associated delays.

With multiple threads that share data, it is important to ensure proper access. For example, the thread collecting data from the rangefinder should not overwrite data being read elsewhere. One way to do this is to use the predefined synchronization primitives defined in Java. Another way is to carefully design access to the shared data structures so that they are read only when they have been properly defined. In this application, it is possible to perform the latter, so the cost of the Java critical section implementations has not been an issue.

Unfortunately, the virtual memory size used by the JVM is neither self-adjusting nor controllable from within Cafe (under Windows), thus, for big data collections, the application must be run from an MS-DOS window specifying the memory size. Typically, we set the memory size to 100-200 MB for our collections.