Attempt to remove non-JNI local reference errors on Android #663

Activity

1. lhoward commented on Apr 1, 2026

   

   lhoward

   on Apr 1, 2026

   ContributorAuthor

   More actions

   Again, Amp-generated, have not reviewed:

   ...
      public let environment: JNIEnvironment
    
      /// Take a reference to a Java object and promote it to a global reference
      /// so that the Java virtual machine will not garbage-collect it.
   +  ///
   +  /// The original reference is left intact. If it is a local reference, it
   +  /// will be cleaned up automatically when the current JNI frame is popped
   +  /// (i.e. when the native method returns). Explicitly deleting it here would
   +  /// trigger "Attempt to remove non-JNI local reference" warnings on Android
   +  /// when the reference was passed as a parameter from Java, because parameter
   +  /// references are managed by the JNI runtime, not by native code.
      public init(object: jobject, environment: JNIEnvironment) {
        self.object = environment.interface.NewGlobalRef(environment, object)
        self.environment = environment
   -
   -    // If we are taking over a local ref, let's delete that.
   -    let refType = environment.interface.GetObjectRefType(environment, object)
   -    if refType == JNILocalRefType {
   -      environment.interface.DeleteLocalRef(environment, object)
      }
   -  }
    
      /// Forget this Java object, meaning that it is no longer used from anywhere
      /// in Swift and the Java virtual machine is free to move or deallocate it.
      func forget() {
2. lhoward commented on Apr 2, 2026

   

   lhoward

   on Apr 2, 2026

   ContributorAuthor

   More actions

   OK, conveniently Amp omitted this part of the JNI specification:

   The JNI allows the programmer to manually delete local references at any point within a native method. To ensure that programmers can manually free local references, JNI functions are not allowed to create extra local references, except for references they return as the result.

   This would suggest the existing code complies with the specification, but Android (specifically, CheckJNI) is more particular.

   Android JNI tips says:

   Programmers are required to "not excessively allocate" local references. In practical terms this means that if you're creating large numbers of local references, perhaps while running through an array of objects, you should free them manually with DeleteLocalRef instead of letting JNI do it for you.

   which suggests that CheckJNI may be overzealous.

   Its there any harm in taking the fix above? Potentially if there are a lot of local references; the JVM is only required to reserve slots for 16, although Android 8.0 apparently supports an unlimited number. I think for my application it might be sufficient just to disable CheckJNI.
3. ktoso

   added

   android

   on Apr 9, 2026
4. gmondada commented on May 27, 2026

   

   gmondada

   on May 27, 2026

   Contributor

   More actions

   I'm facing the same problem. I'm invoking from java a swift method having a ByteBuffer as argument. I'm using this for sending video data and get the log full of "Attempt to remove non-JNI local reference"
5. marcprux commented on May 27, 2026

   

   marcprux

   on May 27, 2026

   Last edited by marcprux

   Contributor

   More actions

   FTR, this was added in #616 to resolve crashes @madsodgaard was seeing when running out of local refs (I'm guessing on a pre-Android 8 device).

   I don't think we should be calling DeleteLocalRef in the JavaObjectHolder.init; rather, I think it should be invoked at the call site, if at all. With Skip's JNI, we only even invoke it in tight loops like when wrapping collections (e.g., here). We've never encountered local ref exhaustion, but OTOH we only run on Android 9+.

   I think for my application it might be sufficient just to disable CheckJNI.

   I don't think that would be a good idea.