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
[Java.Interop] JavaObject: GREFs by default, not LREFs.
Fixes: #6
Context: https://trello.com/c/EXxOMZOD/397-add-java-lang-object-unregisterfromvm
After presenting parts of the Java.Interop design to various other
Xamarin employees at the 2014 Xummit, I got lots of pushback about the
idea of not registering JavaObject instances by default and using
JNI Local References by default.
The problem/fear: it would be a usability nightmare. Single-threaded
use kinda/sorta works...if you never leave the method. If another
thread tries to access your JavaObject instance, you blow up. If you
call Java code which calls back into managed code tries to grab that
instance, you may blow up, as the value wasn't registered.
It's not good.
Then there's the future Android side of things: Android only permits
512 JNI local references; allocate more, and you abort.
That's *really* not good.
Partially revert commit 1caf077: don't use JNI Local References, use
JNI Global References, *always*. (This fixes Android.)
Additionally, register JavaObject and JavaException instances by
default. Allow them to be *unregistered* via the new
IJavaPeerable.UnregisterWithRuntime() method, *or* the new
JniObjectReferenceOptions.DoNotRegisterWithRuntime enum value.
The former will remove an existing registration; the latter will
prevent it from being registered AT ALL [0].
[0]: This is a lie: we'll register the instance for the duration of
the constructor, the unregister it automatically [1].
[1]: I'm not sure if this is a good idea or not. On the one time, we
*need* the registration within the constructor to support
Java-side invocation of virtual members: the instance MUST be
registered so that we lookup the appropriate instance for
virtual method dispatch at a later point in time.
However, it also means that it *is* being registered, if only
for a short period, and thus when sharing an instance from
multiple threads, each trying to register/unregister, things may
fail badly; see e.g. [2, 3]
This idea requires further consideration; yet another reason
JavaObject isn't ready for Xamarin.Android integration.
[2]: https://bugzilla.xamarin.com/show_bug.cgi?id=14999
[3]: xamarin/monodroid@8138649
0 commit comments