Bug 42476 - Java.Interop.dll is built using DEBUG conditional
Summary: Java.Interop.dll is built using DEBUG conditional
Alias: None
Product: Android
Classification: Xamarin
Component: BCL Class Libraries ()
Version: 6.0.0
Hardware: PC Windows
: Normal normal
Target Milestone: 7.1 (C9)
Assignee: Jonathan Pryor
Depends on:
Reported: 2016-07-12 03:48 UTC by Jerome Laban
Modified: 2017-02-21 20:43 UTC (History)
4 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Jerome Laban 2016-07-12 03:48:04 UTC
In Xamarin.Android for VS2015, Java.Interop.dll is built using DEBUG conditionals, making 

   JniObjectReferenceManager.AssertCount(int count, string type, string value)
   JniObjectReferenceManager.AssertReferenceType(ref JniObjectReference reference, JniObjectReferenceType type)
available at runtime. Those two meshots take a lot of CPU when managing references, making useless string.Format calls.
Comment 1 Jonathan Pryor 2016-07-12 16:56:11 UTC
> Those two meshots take a lot of CPU when managing references,
> making useless string.Format calls.

Does it? As per Bug #41733, the overhead from those methods is negligible so long as the asserts don't actually fire:


> Xamarin.Android 6.0 results: 264-351ms


> Xamarin.Android 6.1 + "workaround": ~240-300ms


> [the patch] appears to have alleviated the performance problem.
Comment 2 Jonathan Pryor 2016-07-12 16:58:59 UTC
A closely related question is, how useful do you want the JNI Local Reference count to be? If you don't care at all, then the assert is meaningless. If you won't want completely "funky" negative numbers, then the assert is meaningful because it shows a problem.

Another issue is our distribution process: at present we have no facility to provide both Debug and Release-compiled assemblies. (I can *imagine* one, but it doesn't currently exist.) For years we've actually been shipping Debug-compiled assemblies, and it hasn't been a problem, but we also haven't had lots of asserts either...so that might be why, and it might be prudent to start looking into shipping both Debug- and Release-compiled assemblies.
Comment 3 Jerome Laban 2016-07-12 17:01:04 UTC
The asserts don't fire, but both string.format is always executed, that's what is costly enough to appear in the profiler on a simulator.

And for the other counters, I was not aware those may be useful at all, so I don't have on opinion on this...
Comment 4 Jerome Laban 2016-07-12 17:02:51 UTC
And I agree with the problem of distribution, though a unconditional method call is cheap enough that having a check for a static variable can enable these asserts, if necessary.
Comment 5 Jonathan Pryor 2016-07-12 21:10:58 UTC
The unnecessary string allocations are h handled with: https://github.com/xamarin/java.interop/pull/55
Comment 6 Jonathan Pryor 2016-07-28 19:55:02 UTC
Addressed in:

* https://github.com/xamarin/java.interop/commit/f70d356c
* monodroid/master/3ef12f00
* monodroid/cycle8/6fb52c6f
Comment 7 Saurabh 2017-02-02 10:17:30 UTC
@Jonathan, I have tried to reproduce this Issue using attached project mentioned in https://bugzilla.xamarin.com/show_bug.cgi?id=41733#c0, Application getting deployed and launched on device but I am not sure where I can check CPU utilization for those two meshots.

Could you please let me know how can I reproduce this Issue so that I can verify it.
Comment 8 Peter Collins 2017-02-21 20:43:38 UTC
This already shipped in Cycle8. Marking as verified after validating the code change is also present in Cycle9.