I've been in touch with Xamarin, and they have made a number of useful suggestions, one of which applies to your existing code.
This is to Dispose the Java.Util.Date and Java.Lang.Double as soon as they are added to the data point - once they are added to the DataPoint, the native side object is referenced, and the managed side object can be GC'd. This will ensure that the Date and Double GREFs are immediately freed, reducing the GREF count from 3 to 1.
Similarly, the DataPoints can be disposed as soon as they have been added to the DataAdapter, for the same reason.
This works as long as no subclassing is required, e.g. DataPoint can be used unchanged - your StockDataPoint won't allow this to work..
While this reduces GREF use and corresponding GC times, it won't help much with JNI execution time. Creating each DataPoint instance involves 7 JNI invocations (3 instance creations + 2 field settings + 2 Dispose()s).
Overall, they found the performance figures unsurprising, given the JNI invocation overhead. Basically this is part of the trade-off involved in using Xamarin bindings.
Architecturally, I see that your code creates all the data, including reading it in from a csv file, at the moment the user first clicks the button. Obviously, this was just sample code to illustrate the issue, but would it be possible to do this in advance?
We will be looking at providing some Xamarin-specific extensions to the DataAdapter classes, and I have placed it on our backlog. However this work is competing in priority with a number of core features requested by many of our customers and will need to be compatible with the multi-valued data points required for financial series in future releases. We will not, therefore, be adding it immediately.