Trouble creating a Java VM in mixed-language image

[Fletcher Curry]

I have a C function that creates a Java virtual machine:

#include
void CREATE_VM() {
JavaVM *vm;
void *env;
JavaVMInitArgs vm_args;

vm_args.version = JNI_VERSION_1_4;
vm_args.nOptions = 0;
vm_args.ignoreUnrecognized = TRUE;

JNI_CreateJavaVM(&vm, &env, &vm_args);
}

When I link this with a C mainline, like this:

void CREATE_VM();
void main() { CREATE_VM(); }

it completes successfully. When I link it with a BASIC mainline, like this:

call CREATE_VM()

it aborts with a memory management violation. I've tried this with Java 1.4.2 and 1.5.0 on OpenVMS V7.3-2. Any ideas why this is happening or how I can successfully call Java from BASIC?

Here's the MEMMANVIO stack dump:

%BAS-F-MEMMANVIO, Memory management violation
-BAS-I-USEPC_PSL, at user PC=80AEAB60, PSL=0000001B
-SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000000000000, PC=FFFFFFFF80AEAB60, PS=0000001B
-BAS-I-FROMOD, In module MAIN
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
LIBRTL 0 000000000007093C FFFFFFFF8089A93C
LIBRTL ? ?
DEC$BASRTL 0 000000000000EF9C 0000000000040F9C
----- above condition handler called with exception 0000000C:
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000000000000, PC=FFFFFFFF80AEAB60, PS=0000001B
----- end of exception message
0 FFFFFFFF8009609C FFFFFFFF8009609C
DECC$SHR 0 0000000000142B60 FFFFFFFF80AEAB60
DECC$SHR ? ?
DECC$SHR 0 00000000001427A8 FFFFFFFF80AEA7A8
DECC$SHR ? ?
JAVA$JAVA_SHR JAVA_PROPS_MD setPathEnvironment
11095 0000000000000284 00000000009F4144
JAVA$JAVA_SHR JAVA_PROPS_MD GetJavaProperties
11501 00000000000009C0 00000000009F4880
JAVA$JAVA_SHR SYSTEM Java_java_lang_System_initProperties
15593 0000000000000094 00000000009EC234
0 000000004000E5FC 000000004000E5FC
JAVA$FVM_SHR 0 00000000000CF14C 000000000066D14C
JAVA$FVM_SHR ICALL make_native_call 40313 00000000000009BC 0000000000660B2C
JAVA$FVM_SHR INTERP interpret 42533 0000000000000168 000000000060D2E8
JAVA$FVM_SHR INTERP enlarge_stack_and_interpret
43699 00000000000002D4 000000000060D454
JAVA$FVM_SHR INTERP interpret 42554 0000000000000000 0000000000000000
JAVA$FVM_SHR JNI jni_call 44626 000000000000116C 00000000006134BC
JAVA$FVM_SHR JNI jni_CallStaticVoidMethodA
45016 000000000000214C 000000000061449C
JAVA$FVM_SHR JNI jni_CallStaticVoidMethod
45035 0000000000000000 0000000000000000
JAVA$FVM_SHR THREAD thread_init_main
59346 00000000000031CC 000000000064688C
JAVA$FVM_SHR JVM JNI_CreateJavaVM 48778 00000000000003D4 000000000061A474
MAIN CREATE_VM CREATE_VM 3528 0000000000000050 00000000000200E0
MAIN MAIN$MAIN MAIN$MAIN 1 0000000000000054 0000000000020054
PTHREAD$RTL 0 0000000000055D58 00000000006F5D58
PTHREAD$RTL 0 0000000000030404 00000000006D0404
0 FFFFFFFF80261ED4 FFFFFFFF80261ED4

[Volker Halle]

Fletcher,

from your traceback info, the ACCVIO (access to virtual address = 0) happens in DECC$SHR when called from JAVA_PROPS_MD setPathEnvironment

ACCVIOs with VA=0 typically indicate missing/invalid parameters being passed to a called routine.

If you write a C MAIN routine, which calls the BASIC routine, which then calls the JAVA VM, this may work. I'm assuming some initialization code from starting the C main program sets up things, which JAVA is expecting later-on.

Volker.

[Craig A Berry · Accepted solution]

My guess would be that any use of JNI has implicit dependencies on the C run-time environment. Since your BASIC program will not have a main() function like every C program does, you'll probably have to call DECC$CRTL_INIT, as documented for the C run-time. Try the following to get started:

$ help cc run decc$crtl_init

[Fletcher Curry]

Craig, That did the trick! I added a call to DECC$CRTL_INIT at the top of CREATE_VM and it can now be called from either language.

Volker, I'm guessing that your solution would also work, but I'm glad I don't have to write C wrappers for all of my existing BASIC programs, just so I can modify them to call my new JNI routine.

Thanks for your help!

- Fletcher