You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However, if access it correctly synchronized it would still be a memory leak because the map would constantly grow and is never cleared.
Would it maybe make sense to make this an instance field (i.e. remove static)? Though I am not very familiar with this project and what performance implications this would have.
The text was updated successfully, but these errors were encountered:
The method map serves as a sort of vtable for looking up the Java method to use for handling a given Objective-C method selector. Each subclass of NSObject will have a corresponding entry. Conceptually this is static with a one-to-one correspondence between a Java class and a method table.
To satisfy your concern about growing without bound, perhaps it should be changed to a WeakHashMap so that if the class is GC'd, its method table will be cleaned up.
Ah, right then it would likely not be a memory leak because there will only be a limited amount of classes. But using a WeakHashMap might be useful nonetheless to allow removal when a custom class loader which loaded the class is unloaded? However, that might make synchronization more complicated / inefficient.
The field
NSObject.methodMap
is of typeHashMap
and is accessed without any synchronization:Java-Objective-C-Bridge/src/main/java/ca/weblite/objc/NSObject.java
Line 72 in 62409c5
However, if access it correctly synchronized it would still be a memory leak because the map would constantly grow and is never cleared.
Would it maybe make sense to make this an instance field (i.e. remove
static
)? Though I am not very familiar with this project and what performance implications this would have.The text was updated successfully, but these errors were encountered: