The opcode invokeinterface is not implemented, but it is an important one!

We do not have a real implementation of class loaders at the moment.

Downloading vm/rt.jar (60 MB) Error downloading object: vm/rt.jar (bbdd2f5): Smudge error: Error downloading vm/rt.jar (bbdd2f5909ea77fa115f03a2b030f231cc4bf720528b0436f83459a2be429349): batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.

Need to expose the various attributes of the objects in a class file. At the moment, only some of them are parsed.

• class attributes
  • InnerClasses
  • EnclosingMethod
  • synthetic
  • signature
  • SourceFile
  • SourceDebugExtension
  • deprecated
  • runtime visible annotations
  • runtime invisible annotations
  • BootstrapMethods
• methods
  • code
    • exception tables
    • attributes
      • LineNumberTable
      • LocalVariableTable
      • LocalVariableTypeTable
      • StackMapTable
  • source code mappings
  • attributes
    • synthetic
    • signature
    • deprecated
    • exceptions
    • runtime visible annotations
    • runtime invisible annotations
    • runtime visible parameter annotations
    • runtime invisible parameter annotations
    • annotation default
• field
  • attributes
    • constant value
    • synthetic
    • signature
    • deprecated
    • runtime visible annotations
    • runtime invisible annotations

We need to deallocate objects eventually 😅

We need to parse generics correctly and to suppor them in the VM.

Need to support a concept of "classpath" in the vm.

Also, class loaders should be a hierarchy - not sure if this should be done at the same time as the classpath or not.

We need to support multiple threads.

The vm does not support arrays currently. We need to implement:

• primitive arrays
• object arrays
• multidimensional arrays

We only support int and float. Long/double are complex because they take two slots in the local variables, but we need to handle them.

Test for Java Code:

package rjvm.test;

import java.io.PrintStream;

public class Test {
    public static void main(String[] args) {
        final PrintStream p = System.out;
    }
}

#[test_log::test]
fn invoke_test() {
    let mut vm = Vm::new(DEFAULT_MAX_MEMORY);

    let src_dir = env!("CARGO_MANIFEST_DIR");

    vm.append_class_path(&format!("{src_dir}/rt.jar;{src_dir}/tests/resources"))
        .expect("should be able to add entries to the classpath");

    let _ = invoke(
        &mut vm,
        "rjvm/test/Test",
        "main",
        "([Ljava/lang/String;)V",
    );
}

run result (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)

The VM does not support exceptions currently.

there is a java method named "xxx" which calls a native function from native lib,
how to invoke xxx from rust side?

VM has a lifetime 'a. This lifetime is arbitrary – it is chosen by the caller with no restrictions. This means it can outlive the VM, but other structs assume the VM is life for 'a. This is unsound.

Segfaulting example:

    let mut vm = create_base_vm(DEFAULT_MAX_MEMORY);
    let call_stack = vm.allocate_call_stack();
    let main_method = vm
        .resolve_class_method(
            call_stack,
            "rjvm/SimpleMain",
            "main",
            "([Ljava/lang/String;)V",
        )
        .expect("should find main method");
    drop(vm);
    println!("{main_method:?}");

Possible solutions:

• Remove lifetime from VM. All methods that produce lifetimed objects take their lifetime from the reference to the VM.
• Remove lifetime from VM. Keep VM in an Arc. Erase lifetimes internally. Don't hand out structs referencing VM memory directly, instead hand out a wrapper object that also contains a copy of the Arc (this can be transparent to the user).

Aastore cannot store nulls (trying to do so generates a ValidationException).

The API allows data (CallStack, AbstractObject, ClassRefm …) managed by one VM to be used with another VM. This allows e.g. storing a pointer to an object on the heap of vm1 in a static field in the heap of vm2. If a garbage collection then triggers on vm1, the static field on vm2 now points to cleared/invalid data.