Problem with USE_INTERPRETER

[dennis508]

USE_INTERPRETER returns incorrect results when running ExifTool. There are many fails in the ExifTool test suite. Here is one test case:

cd /path/to/exiftool-test-images
#perl
time exiftool -a -make -model -imagesize Canon.jpg Nikon.jpg Sony.jpg
======== Canon.jpg
Make                            : Canon
Camera Model Name               : Canon EOS DIGITAL REBEL
Image Size                      : 8x8
======== Nikon.jpg
Make                            : NIKON
Camera Model Name               : E775
Image Size                      : 8x8
======== Sony.jpg
Make                            : SONY
Make                            : SONY
Camera Model Name               : DSC-F828
Camera Model Name               : DSC-F828
Image Size                      : 8x8
    3 image files read
real    0m0.226s


#jperl
time /path/to/jperl /path/to/exiftool -a -make -model -imagesize Canon.jpg Nikon.jpg Sony.jpg
...same correct results as above...
    3 image files read
real    0m6.595s


#jperl force interpreter
export JPERL_INTERPRETER=1
time /path/to/jperl /path/to/exiftool -a -make -model -imagesize Canon.jpg Nikon.jpg Sony.jpg
======== Canon.jpg
======== Nikon.jpg
======== Sony.jpg
Make                            : SONY
Camera Model Name               : DSC-F828
    3 image files read
real    0m4.340s

Also, please note that the CompileOptions switch useInterpreter does not seem to "stick." I see breakpoints at PerlLanguageProvider.needsInterpreterFallback where the interpreter switch value is false.

CompilerOptions options = new CompilerOptions();
options.fileName = "<init>";
options.code = initScript;
options.useInterpreter = true;

PerlLanguageProvider.executePerlCode(options, true);
...
RuntimeScalar processImage = GlobalVariable.getGlobalCodeRef("main::process_image");
...
RuntimeList rlist = RuntimeCode.apply(processImage, args, RuntimeContextType.SCALAR);

Running this way I get correct results until I set
public static final boolean FORCE_INTERPRETER = true;
in RuntimeCode.java.

[fglock]

Thank you for reporting this issue and for the detailed reproduction case! This is very helpful.

About the Interpreter Mode

The JPERL_INTERPRETER environment variable and useInterpreter flag are internal debugging features intended for development and testing purposes. They're not currently designed for production use. The interpreter backend exists primarily to:

1. Help debug compiler issues by providing an alternative execution path
2. Support edge cases where bytecode generation is incomplete
3. Enable rapid prototyping of new features

We're curious to know more about your use case - what is your interest in using the interpreter mode? Understanding your needs would help us prioritize improvements.

Current Status

We are actively working on feature parity between the JVM and interpreter backends. The interpreter is designed to be a drop-in replacement for the JVM backend, but there are still edge cases where behavior differs. Your ExifTool case helps us identify these gaps.

The parity work involves ensuring both backends handle context propagation, metadata, closures, and complex control flow identically. We'll investigate what specific construct in ExifTool triggers the different behavior.

Regarding "useInterpreter doesn't stick"

There are two ways to enable interpreter mode: [EDIT]

1. JPERL_INTERPRETER=1 environment variable - This sets a global flag that affects all code compilation, including require, do, and eval. This is the recommended way to run fully in interpreter mode.

2. CompilerOptions.useInterpreter - This only affects the specific code being compiled with those options. Subroutines loaded via require or compiled later may use the default (JVM) backend unless the global flag is also set.

If you need consistent interpreter behavior throughout your application, use the environment variable rather than the programmatic option.

Workaround

For now, we recommend using the default JVM backend for production ExifTool usage. It executes faster and is more feature complete.

---

Please let us know about your use case for the interpreter mode - we'd appreciate the feedback!

[dennis508]

Thank you for the information. I have no specific need for an interpreter mode. I was just looking for a faster execution mode. I wondered if ExifTool, being an atypical program, would perform faster in that mode. My ultimate interest is packaging PerlOnJava in my Android app, FastPhotoTagger. Currently this app contains ExifTool plus four(!) compiled subsets of Perl, one for each Android target architecture. The apk size is 14 MB. My hope was that a Perl running on jvm could approach compiled Perl in size and speed. I recognize that PerlOnJava is in early stages and performance cannot have been a big priority up to now. But I note that there is a big difference in speed between compiled Perl and PerlOnJava running ExifTool on Linux. I wanted to explore all execution modes of PerlOnJava.