1. splitsurround's Avatar
    Anyone know if there's an application that simply gives you an alert when your phone memory is down to a preset amount? I'm thinking 1MB. As soon as I see/hear that alert, I do a battery pull and it resets.

    This just seems easier than having to constantly check on the memory drain.

    I'm using a Verizon 8830 for what it's worth, running os 4.2 (on a BES, so I have NO idea when I'll be upgraded to 4.5, or if I ever will).

    Thanks,

    split
    06-30-08 02:51 PM
  2. newhideblog's Avatar
    I recommend you to try MemoryUp - Mobile RAM Booster for BlackBerry. I have been using it for half a year till now. It helps me fix my BB crashes for a couple of times. And it also have the "Low Memory Alert" function, which allows you to set a predefined memory threshold on its setting page.

    You can search in this forum for more reviews on MemoryUp. It is a very useful tool. And the company's customer service is very good.

    Hope that helps!
    07-03-08 05:35 AM
  3. jeffh's Avatar
    I've not used MemoryUp, and so can't comment on it directly. However, three points you should consider: 1) any app you buy to monitor your memory is using some of that memory. You have to decide if the tradeoff is worth it. 2) If you use an alert program, 1 MB is far too low to set your alarm. Low-memory related issues begin when you get below 10-12 MB. 3) Regardless of 1) or 2), you need to run Stoner's memory freeing procedure, found here: http://forums.crackberry.com/f3/how-...-memory-34633/
    07-03-08 06:18 PM
  4. patrick.waugh's Avatar
    Anyone know if there's an application that simply gives you an alert when your phone memory is down to a preset amount? I'm thinking 1MB. As soon as I see/hear that alert, I do a battery pull and it resets.

    This just seems easier than having to constantly check on the memory drain.

    I'm using a Verizon 8830 for what it's worth, running os 4.2 (on a BES, so I have NO idea when I'll be upgraded to 4.5, or if I ever will).
    Well, if you understood a bit more about how memory allocation works on the JVM (Java Virtual Machine) you'd understand that this is not really a good idea for several reasons.

    As Jeff mentions, things (programs and data object) take up memory on your unit, which is in very limited supply, much more so than say on a desktop computer. Processing power is also at a premium, although improving all the time.

    The way the JVM works is a bit different too. In a C++ program, the programmer manages memory completely, deciding when to allocate memory for an object, and when to deallocate that memory when the object is no longer needed. In fact, a significant amount of programming is required to do this memory management, and it is error prone with inexperience programmers often inadvertantly creating memory leaks. This occurs when a program requests the allocation of memory from the "heap" (pool of memory), and never releases it, even though the object is no longer used. If that program continues to run, and continues to allocate duplicate objects, eventually there is no more to be allocated, and the allocation and hence the program fail.

    In Java (the JVM) memory leaks are not at all an issue in a properly written program because memory allocation and object destruction and memory deallocation are handled entirely by the JVM's garbage collector (GC). When all references to an object go out of scope, that object is then marked as "recoverable", meaning, the GC is free to recover it's memory for use in a new object.

    So, what happens is you begin with a limited and fixed amount of memory. You run a couple of programs in the background which consume some, and another program that you terminate. The background programs are maintaining some memory consumption for some (not all) of the object they use, but have "released" some, and the program you have terminated has released all of the objects it has used.

    However, that memory is not YET free! It is not freed, and collected by the Garbage Collector until either your CPU is idle (not busy doing something important), OR memory has reached a low enough level the GC kicks in out of necessity. You'll know when that happens because that is when you get the pause and hour glass rotating for 2 seconds (about the longest it takes to collect all the memory).

    So, given the above, the amount of "free" memory reported, is not really the amount of memory available, just the amount available without the GC doing it's thing.

    Most of the time the GC is able to do it's stuff behind the scenes unnoticed, and keep us happy. While you should have at least 1.5 Megs free when you start, you can quite happily operate with that memory being virtually completely alllocated (showing literally zero free memory) - provided the software you are using is properly programmed to not hog resources.

    Finally, you should know that pulling your batter is NOT good for your system, nor indicated "because memory is low". If your memory becomes low, allow your device time to do it's GC. 99% of the time when someone thinks their berry is unresponsive due to low memory it is because they have failed to close programs, but instead have sent a number of them to the background, thus consuming precious memory and CPU cycles that would otherwise be free to allocate to the current task.

    So, if your system becomes sluggish, you first want to close any unnecessary background tasks, and then give your GC time to clean up the mess you made of memory. =)

    If you are in a big hurry, you can soft-reset your device which will instantly clear memory, but DO NOT pull the battery. ONLY pull the battery when the system locks up, and you cannot do a soft-reset or power off.

    Others will try to tell you different, even some CSR's who don't know any better, and it has become a standard support technique because it is fast and easier than doing things right, but it can actually result in a serious JVM error that will require a complete wipe and reinstallation of your OS!

    I have NEVER pulled the battery EVER on my 8820 that I currently own, and I program the thing and install my own alpha (read unstable) software all the time!

    The ONLY exception to the above is if you have no recourse because due to an OS error, you have fixed icons (like a VM icon that won't go away). However, the PROPER & SAFE procedure is to power off, THEN remove your battery for 15 seconds.

    One other rare occurance that might require this procedure is when some software you have deleted has not properly clear it's persistent store, and the symptom of that will be varied, but likely that reinstallation fails without the clearling of the persistent store throught complete power down.

    Hopefully, some of you reading this will find this informative. It's your Berry though, so if you want to risk reinstalling the OS, go right ahead!
    07-04-08 12:58 PM
  5. jeffh's Avatar
    Patrick, Thanks for an excellent and informative post. Your battery-pull comments are sure to spark a lively debate. My programming days ended in FORTRAN77 (yes, I lived with the dinosaurs!), but surely, as often as we've told people to pull their batteries, there must be something else in play, or we'd read many more stories about bricked BB's than we do. What is it about pulling the battery that can result in a serious JVM error that requires a wipe and reinstall, yet usually doesn't?
    Last edited by JeffH; 07-04-08 at 01:25 PM. Reason: grammar
    07-04-08 01:24 PM
  6. patrick.waugh's Avatar
    Patrick, Thanks for an excellent and informative post.

    Your battery-pull comments are sure to spark a lively debate. My programming days ended in FORTRAN77 (yes, I lived with the dinosaurs!), but surely, as often as we've told people to pull their batteries, there must be something else in play, or we'd read many more stories about bricked BB's than we do. What is it about pulling the battery that can result in a serious JVM error that requires a wipe and reinstall, yet usually doesn't?
    It is true that "it usually doesn't" result in the dreaded JVM error. "It" is all about luck basically.

    The error in question is more of a security feature actually. The JVM "monitors" memory in some sense to ensure it does not become corrupted either by hardware failure, or malicious software attempting to bypass security. What can happen is that as you suddenly remove power (the battery), bits in memory can become corrupted. If those bits are in software that is stored, when the JVM reboots it will detect the "unauthorized" modification to software, and throw a security excpetion, and then basically kill the JVM. This is, in fact, why unplugging from the USB before software installation is complete can be so devistating.

    It doesn't happen often, but such transient power spikes are not good for the hardware, and over time the memories PN juctions will become "worn". As with any computer, ideally you want to avoid powering it up and down (not talking about standby here, but powering off).

    Some older Berryies might require battery pulls due to early versions of the OS having problems, and there being no soft-reset, but I'm not an expert on older berries (anything before 8800, 8100, 8300).
    07-04-08 01:41 PM
  7. patrick.waugh's Avatar
    After reading the above, I think we need a "term" for when a user (vs. mis-behaving program) creates a memory "leak" (ie inadvertantly allocates all available memory with background tasks).

    Rather than "memory-leak" we should maybe call it "DEU Syndrome" for Defective End-User Syndrome. =)

    I don't know, you're from NASA, come up with some million dollar NASA term for it that sounds impressive.
    07-04-08 01:56 PM
LINK TO POST COPIED TO CLIPBOARD