GREF increasing / decreasing in multi-threaded service (aidl) - what does it mean?

Question

I have an android activity and a service implemented using aidl. Works like a champ, I have a callback setup to pass some thread notifications back to the UI, and that appears to work fine, with the exception of lots of

GREF has increased to 101, 201,301,401, 501.. etc, and GREF has decreased. I did some searching online and found that it has to do w/ Global References.

08-17 02:31:19.735: DEBUG/dalvikvm(2558): GREF has increased to 301
...
08-17 02:31:25.823: DEBUG/dalvikvm(2558): GREF has increased to 401
...
08-17 02:31:36.772: DEBUG/dalvikvm(2558): GREF has increased to 501
...
08-17 02:31:42.694: DEBUG/dalvikvm(2558): GREF has increased to 601
...
08-17 02:31:48.695: DEBUG/dalvikvm(2558): GREF has increased to 701
... 
08-17 02:31:59.883: DEBUG/dalvikvm(2558): GREF has decreased to 599
08-17 02:31:59.912: DEBUG/dalvikvm(2558): GREF has decreased to 499
08-17 02:31:59.912: DEBUG/dalvikvm(2558): GREF has decreased to 399
08-17 02:31:59.912: DEBUG/dalvikvm(2558): GREF has decreased to 299
08-17 02:31:59.912: DEBUG/dalvikvm(2558): GREF has decreased to 199

I did some searching and see that most of the remarks on this are rather old. My concern is that I am implementing my client/service correctly, and wanted to know how I can track down what is causing GREF to increase. Any thoughts / suggestions are welcomed. Thanks!

Basic Program Flow

Client -> Creates Callback
Client -> Starts Service
Service -> Inits & Starts CountDownTimer
Service.CountDownTimer.onFinish() -> DownloadAndParse()
DownloadAndParse() -> initialize new saxRequest(), new Handler for this request.
Service.Handler->beginBroadcast()
Client.CallbackStub -> updateUI()
Client.CallbackStub -> service.startCountDownTimer()

Hopefully this makes sense. I would post code here, but there is so much in so many different files. I figured I would try and put the flow up to see if there is anything glaring... The only thing I can see is maybe re-using the saxRequest() rather than creating a new instance... I will try that now actually, but I would really like to know about the impact of the GREF and the Garbage Collection..

Answer 1

These are JNI global references. If you're not writing native code, you don't have direct control over them. The log messages appear when CheckJNI is enabled, which is on by default for engineering builds and the emulator.

The messages just mean that native code is telling the VM that it's not allowed to discard some objects. In essence, global refs are a way for native code to add references to the GC's root set. Assuming the native code is written correctly, the global refs will be cleared when the native code no longer has need of them.

The only cause for concern would be if the global ref count continued to climb, as that would suggest a global reference leak. Since the VM can't free the objects, a global ref leak will eventually cause the VM to run out of memory. To help identify such problems, a cap is placed on the number of global references when CheckJNI is enabled (current limit is 2000).