Questions on memory leaks and exit practices.

[Hotrootsoup]

According to cowlark,

Whenever you load a class containing static members, the memory used for those members will never be freed. Ever.

Is this outdated, or is it really still a problem?

If it is a problem, can someone explain it a little further? Is it just static members I'm setting in the classes I use, or are includes also wasting memory until the kindle is reset? Again, if so, would two apps include-ing the same class cause twice the amount of memory wasted, or is it limited to one per Java class name?

Even supposing that isn't true at all, how do you all shut down your apps? Not necessarily what technique you use to avoid the home button, but how do you clean up? What can I trust the garbage collector with?

[ixtab]

Quite simply: the statement is completely wrong.

A static member is just a member that is not associated with an instance of a class, but with the class itself (rather: with its class object). And unlike "normal" objects (class instances), class objects will not be garbage-collected as long as the class is loaded, because they don't go out of scope or become orphaned. So far, so correct.

However -- and this is the important point -- every Kindlet is instantiated in its own, isolated, classloader. All of the classes and instances of that Kindlet only ever live inside that classloader. And when the Kindlet is terminated - poof! - the class loader and everything that was "produced" by it is discarded and can be garbage-collected. Unless there are memory leaks inside the JVM implementation, this is no problem at all, and the statement simply shows a lack of understanding of how the class loading mechanism works and is implemented on the Kindle. (more technically, we're talking about ClassLoader delegation and isolation... ask your favorite search engine about it).

Admittedly, this is not the easiest topic to wrap your head around, but the Kindle uses the same technique as any other "application server"/"web container"/whatever you want to call it. If it didn't work, half of the WWW would constantly be crashing because of OOM errors

That said, yes: the Kindle does have rather severely limited memory, and if you aren't careful, it's relatively easy to hit the roof. But the problem that you're referring to just isn't a problem.

[Hotrootsoup]

Awesome, thank you very much for the reply!

I hope to be active in this community for a while, very tempted to write an IRC client at the least.

[knc1]

Originally Posted by Hotrootsoup

Awesome, thank you very much for the reply!

I hope to be active in this community for a while, very tempted to write an IRC client at the least.

We already have one of those posted on this site.
You might want to check it out before starting your own version.

Not that we have any objection to having more than one flavor of anything posted, just that it might save you some time.

[NiLuJe]

So err, keeping in mind that I'm terrible at Java, and when Hotroot mentioned this on IRC it reminded me of it:

What does those mean in the logs, when closing a Kindlet (KUAL, in this case):

   130805:223901 cvm[1738]: I GarbageMonitor:GarbageMonitorInfo:status=eligible,description=KindletClassLoader for appId= test,object=1081632425:Can now be collected
   130805:223901 cvm[1738]: I GarbageMonitor:GarbageMonitorInfo:status=collected,description=KindletThreadGroup for appId= test,object=43152587:Collected
   130805:223901 cvm[1738]: I GarbageMonitor:GarbageMonitorInfo:status=collected,description=KindletClassLoader for appId= test,object=1081632425:Collected
   130805:223901 cvm[1738]: D StandardKindletContainer:GenericDebug::AppContext.dispose() failed to shut down ThreadGroup correctly; waited some time and now about to invoke ThreadGroup.destroy() directly. Details of active threads are: 
   130805:223901 cvm[1738]: I GarbageMonitor:GarbageMonitorInfo:status=watch,description=Cleanup Thread for static variables in Kindlet,object=-1528622242:Watching
   130805:223901 cvm[1738]: D StandardKindletContainer:GenericDebug::Unable to clear static field
   130805:223901 cvm[1738]: D StandardKindletContainer:GenericDebug::Unable to clear static field
   130805:223901 cvm[1738]: D StandardKindletContainer:GenericDebug::Unable to clear static field
   130805:223901 cvm[1738]: D StandardKindletContainer:GenericDebug::Unable to clear static field
   130805:223901 cvm[1738]: D StandardKindletContainer:GenericDebug::Unable to clear static field
   130805:223901 cvm[1738]: W StandardKindletContainer:GenericWarning::Error occured while cleaning up Kindlet application classes
   130805:223901 cvm[1738]: D StandardKindletContainer:GenericDebug::Unable to clear static field
   130805:223901 cvm[1738]: D StandardKindletContainer:GenericDebug::Unable to clear static field
   130805:223901 cvm[1738]: D StandardKindletContainer:GenericDebug::Unable to clear static field
   130805:223901 cvm[1738]: D StandardKindletContainer:GenericDebug::Cleanup of statics took: 19 milliseconds
   130805:223901 cvm[1738]: D BookletSandboxKindletProcess:GenericDebug::After shutting down sandbox, un-cleaned windows remaining = 0
   130805:223901 cvm[1738]: D BookletSandboxKindletProcess:GenericDebug::kindlet process destroyed
   130805:223901 cvm[1738]: D AbstractBooklet:Entering stop:booklet=com.lab126.booklet.kindlet:
   130805:223901 cvm[1738]: D AbstractBooklet:DebugInfo::Removing all chrome header button listeners for booklet com.lab126.booklet.kindlet
   130805:223901 cvm[1738]: I KindletBooklet:stop:timeTaken=2058,freeMemory=9517180,lifecycleEventType=switch-out,units=ms:stop

If I understood correctly, basically, it's in a sandbox, and in the end the sandbox itself is destroyed, so we don't care?

[ixtab]

@NiLuJe: in simple terms, yes.

What I wrote above was slightly simplified, because Kindlets of course don't only use classes from their own classloader (but from parent loaders too - like JButton), and they are able to spawn new threads (but only inside their own thread group, so these can again be killed as you see above).

I don't know what the "unable to clear static field" is trying to say exactly - it might be related to not being able to re-assign static final members (setting a field to null is a common measure to help the garbage collector, but it won't work on final fields for obvious reasons), or it might be something else.

But yeah, for all practical purposes, just assume that you don't have to worry about cleaning up after yourself. That's one of the beauties of the JVM. I'm starting and restarting Collections Manager dozens, if not hundreds of times during some dev sessions, and I'm never really experiencing issues that could be related to memory management (well, except if I'm doing stupid things myself ).

[NiLuJe]

@ixtab: Great, thanks for clearing that up

[ixtab]

Originally Posted by Hotrootsoup

Awesome, thank you very much for the reply!

I hope to be active in this community for a while, very tempted to write an IRC client at the least.

We're always happy to see new contributors, so welcome to the community!

Just a few hints:

1. If you're just getting started with Kindlet development, it may help to take a look at the existing Kindlets' source code.
2. If you want to do non-trivial things, like reading/writing files, accessing the network etc. you're likely to need the Kindlet jailbreak sooner or later. You can find examples of its use in the KUAL or Collections Manager Kindlets.
3. Please use the existing "test" certificate instead of creating your own to sign the .azw2 files. See the KUAL sources for an ant script. This way, your Kindlet will work out of the box for users who have the "mobileread dev certs" package installed.

Originally Posted by knc1

We already have one of those posted on this site.
You might want to check it out before starting your own version.

Not that we have any objection to having more than one flavor of anything posted, just that it might save you some time.

I personally think that Kindlets are somewhat underrepresented in all of the various tools that we have here. Of course, it's probably easier to port existing applications, but they will (almost) never integrate as smoothly with the Kindle's look and feel as a Kindlet can. Just my personal, and highly subjective, opinion of course. Plus, they're fun to write *

(*) as long as you don't try to mess with the Kindle internals too much, that is. But that is only due to the close-minded "we do closed source, hands off our device" developers over at lab126. Yeah, I just had to say that again

[Hotrootsoup]

@ixtab

1. I've been looking at a few, but I'll download a few more to get a better overview.

2. I still don't understand the kindlet jailbreaks. I only ever see links to its download page, never a forum page explaining it.

3. Yep, been doing that.

@knc and ix

I assume you're referring to the irssi port? I really didn't like what I saw. I agree that stuff tends to look better when its developed natively, and I'm pretty good with UI stuff.

[twobob]

1) Good call. Check the wiki and do a search on here. (There are various lists)

2) It patches a tiny bit of code in one file. (or replaces it with a good one, I forget) IIRC.
Essentially altering the security scope of kindlets. (extra /mnt/us)

3) Nice one. one less headache.

Further to what Ixtab said, yes kindlets are sorely underused, anyone getting excited about them is a great thing.

[silver18]

Sorry to hijack (also) this thread, but I don't feel like opening a new one for such a small question...
Does anybody here know how does the Garbage Collector work for WAFs?
Is it the same used for the browser or do I need to load it in some way?

I'm a bit concerned on performance and I would like to be reassured on this!

As always, thanks gurus!!

[ixtab]

Originally Posted by Hotrootsoup

@ixtab
2. I still don't understand the kindlet jailbreaks. I only ever see links to its download page, never a forum page explaining it.

It's pretty under-documented, I agree. That's probably because most Kindlets who use it are either (co-)authored by myself , or simply copy/paste the important few lines of code from existing projects. That said, the source code itself is actually quite well documented (and included in the lib/jailbreak.jar that you need anyway, see KUAL or CM sources). Once you include that into the project, you get access to both the Javadoc and source code of the client part.

And here, deeply hidden in the forum dungeons, is the background information (read the entire thread).

HTH