jni: Unify common methods using generic implementations

[sidepelican]

Motivation

As mentioned in the 'Others' section of PR #572, we currently have branching logic in the generator for common functions like destroy, depending on whether the target type is generic or not.

This branching is undesirable as it increases maintenance costs.
While PR #567 partially addressed this by introducing .synthesizedFunction, I have found a better approach, I propose it and solve the problem.

Solution

Instead of generating type-specific code, providing a single generic implementation within the SwiftJava package for functions like toString and destroy.

Since JNISwiftInstance always including type metadata, I realized that we can utilize the technique proposed in this comment to call a generic implementation.

@_cdecl("Java_org_swift_swiftkit_core_SwiftObjects_toString__JJ")
public func Java_org_swift_swiftkit_core_SwiftObjects_toString__JJ(environment: UnsafeMutablePointer<JNIEnv?>!, thisClass: jclass, selfPointer: jlong, selfTypePointer: jlong) -> jstring? {
  let selfTypeBits$ = Int(Int64(fromJNI: selfTypePointer, in: environment))
  guard let selfType$ = UnsafeRawPointer(bitPattern: selfTypeBits$) else {
    fatalError("selfType metadata address was null")
  }
  let typeMetadata = unsafeBitCast(selfType$, to: Any.Type.self)

  func perform<T>(as type: T.Type) -> jstring? {
    guard let self$ = UnsafeMutablePointer<T>(bitPattern: selfPointer) else {
      fatalError("self memory address was null")
    }
    return String(describing: self$.pointee).getJNIValue(in: environment)
  }
  return perform(as: typeMetadata)
}

Pros:

• Significantly simplifies the code generator implementation.
• Greatly reduces the amount of generated code, leading to smaller binary sizes.
• Aligns the implementation more closely with the FFM side.

Cons:

• Increase in runtime overhead:
  • Add calling to runtime functions (SIL's open_existential_metatype).
  • Loss of certain optimizations (e.g., inlining that might skip VWT lookups when individual implementations are generated).

Regarding the downsides, I believe the overhead is negligible compared to the inherent cost of JNI calls.

Changes

Following this new direction, I have replaced the generated code for the following functions with generic implementations:

• toString
• toDebugString
• destroy
• getDiscriminator

Additionally, I have removed .synthesizedFunction as it is no longer needed.

[ktoso]

We should be able to get away with implementing them as

@JavaImplementation("org.swift.swiftkit.core.JavaObjects")
struct SwiftObjects { 
  @JavaStaticMethod
  func getRawDiscriminator(selfPointer: Long, selfTypePointer: Long) -> Int { ... }
}

since SwiftJava depends on the SwiftJavaMacros... I'd like to avoid not-using our own tools in this project, this way it's a good feedback mechanism if something is off or missing, and we avoid the typical mistakes with the cdecls etc.

I forget the exact syntax so sorry if the snippet isn't exactly right above here :)

[sidepelican]

I didn't realize that we can use SwiftJavaMacros here! This would be better.

[ktoso]

👍

[ktoso]

Overall I really like this shape, it's true as you say we take some performance hit here for the opening but perhaps it is worth it anyway.

Would you be able to do a quick benchmark before/after? We have benchmarks set up in the repo, should be quick to add and try.

Overall though I'm supportive of this change, it's a nice pattern we'll likely follow in many more places!