GREF increases / decreases in a multithreaded service (helpl) - what does it mean?

Question

I have android activity and a service implemented using helpl. Works like a champion, I have a callback function to pass some stream notifications back to the user interface, and it looks fine except for a lot

GREF increased to 101, 201,301,401, 501, etc., and GREF decreased. I did a search on the Internet and found that it should 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 saw that most of the comments on this one are pretty old. My concern is that I am implementing my client / service correctly and want to know how I can track what causes GREF to increase. Any thoughts / suggestions are welcome. Thanks!

Main program stream

 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() 

Hope this makes sense. I would post the code here, but there are so many in many different files. I decided that I would try to put a stream in order to see if there is something egregious ... The only thing I see is, perhaps, reusing saxRequest (), rather than creating a new instance ... I will try now, but I I'd love to know about the impact of GREF and the garbage collection.

Answer 1

These are JNI global links. If you do not write your own code, you have no direct control over them. Log messages appear when CheckJNI is enabled, which is enabled by default for engineering assemblies and the emulator.

Messages simply mean that the native code tells the VM that it is not allowed to discard some objects. In fact, global refs are a way for your own code to add links to a set of GC root files. Assuming the native code is spelled correctly, global refs will be cleared when the native code is no longer needed.

The only reason for concern is that the global count continues to grow, as this implies a global link leak. Because the virtual machine cannot free objects, a global ref leak will ultimately cause the virtual machine to run out of memory. To identify such problems, when you turn on CheckJNI (current limit is 2000), the cap is placed in the number of global links.