Page History

...

As a rule, Java objects should own native objects in jlongs

• The jlong type is used because it is big enough to hold both 32 and 64-bit sized pointers
  • Use the jlong_to_ptr() and ptr_to_jlong() macros to correctly handle casting and avoid sign-extension problems
• This keeps the number of JNI global refs HotSpot has to manage to a minimum
  • Java objects should not be pinned in the Java heap until some random native retain count lowers or the ObjC-GC decides to kick in
• Java objects that own native objects have to concretely define the lifecycle of the native objects they hold
  The jlong type is used because it is big enough to hold both 32 and 64-bit sized pointers
  • Use the jlong_to_ptr() and ptr_to_jlong() macros to correctly handle casting and avoid sign-extension problemsDo not let native objects hold onto Java objects in JNI global refs, or you can create a cycle across the Java and ObjC garbage collectors, and neither collector will realize that they can deallocate their respective objects

  Native objects held by Java objects must have a "hard" CF-retain count of 1 before being passed up to Java

  ...