FAQ
The vast majority of the finalizers used on the Seq object are
unnecessary, and are a remnant of when gobind was a multi-process rpc
system. All generated functions of the form "create two Seq objects,
call and wait, extract the value from the Seq objects" can do the
cleanup at the end of the function.

We can go even further. On many existing versions of Android there is
no highly efficient cleanup of young objects (in fact, I haven't
checked how JNI is handled on the latest android, it may be that they
way we use Seq never qualifies for fast cleanup). So we could get a
lot of benefit from a pool of reused Seq objects.

The only reason we haven't done any of this is we've been focused on
making it work, not making it fast. The few gobind based programs we
have are in no way performance limited by the cross-language call, so
it hasn't been a focus. When we have one that is, there's a great deal
to do. I hope to spend some time on it next year. For now, I've filed
https://golang.org/issue/12619.
On Sat, Sep 12, 2015 at 1:41 PM, wrote:
Hello folks,

First off, a big thank you to the gomobile developers and everyone who
contributed to getting go building on android and ios! Being able to write
ios and android app backend code in go feels awesome.

Now, to my question:

Does anyone here have any real world memory usage data for an Android app
using gomobile bind?

The reason I ask is that the use of finalizers in Seq.java is making me
nervous about using 'gomobile bind' in production.

Based on my understanding of the codebase, it looks like every call to a Go
function will create as many new Seq objects as there are parameters. Every
Seq object has an associated finalizer which is called when it is GC-ed.
However, finalizers are generally regarded with suspicion in my experience
and for good reason. There is no guarantee that they'll ever get called in a
reasonable amount of time, especially if the thread they are called on is
starved. The Android javadoc seems to think they're a bad idea as well, with
the additional caution that all Android finalizers are run on a single
system thread.

Relevant portion of the Android javadoc:

"A finalizer is usually only necessary for a class that has a native peer
and needs to call a native method to destroy that peer. Even then, it's
better to provide an explicit close method (and implement Closeable), and
insist that callers manually dispose of instances"
...

If you must use finalizers, consider at least providing your own
ReferenceQueue and having your own thread process that queue.


I'm leery of investing a ton of time into building an app backed by gobind
and then having to debug memory issues in production, hence the question.
Alternatively, if any of you have any experience with finalizer heavy apps
on Android that would be useful as well. Right now, I'm leaning towards just
shipping byte arrays back and forth manually and using protobufs for the
serialization / code gen.

Cheers!
Sridhar

--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 3 | next ›
Discussion Overview
groupgolang-nuts @
categoriesgo
postedSep 12, '15 at 5:41p
activeSep 14, '15 at 9:10p
posts3
users2
websitegolang.org

2 users in discussion

S: 2 posts David Crawshaw: 1 post

People

Translate

site design / logo © 2021 Grokbase