08-04-11 09:11 AM
66 123
tools
  1. cwong15's Avatar
    8 gigs of device memory is again limited to media and document storage. Looks like only approx. 500 megs can be utilized for apps. Based on the latest screen shots provided in the new Torch video thread, looks like after the OS is fully loaded in, there is about 250 megs of app space left.
    We've seen varying accounts about available app memory, though your number is the smallest I've seen yet. I suspect there is an internal limitation of the underlying OS or Java runtime that limits the available app memory. IMHO, this is not a deal breaker. App developers just need to be more intelligent about their use of storage. Developers have dealt with memory restrictions for a long, long time. We know how to work around this.

    Think about your media apps. Do they install all their songs, videos and pictures in app-space along with the media player? How about your book readers (BN reader, Kindle)? We already have apps today that know how to use the rest of that 8GB of flash or whatever you have on your SD card. The really big game apps are mostly graphics/media resources. They can download their resources separately and save them to non-app memory, just like what the Kindle app does today.
    07-14-11 10:13 PM
  2. dkonigs's Avatar
    I have no hard facts - this is just my computer science degree and experience talking so just my 2 cents.
    Um, you know that these are the CrackBerry forums, right? Any actual knowledge of software engineering or computer architecture is forbidden here. Everyone wants to believe that "memory, RAM, flash, and disk space" are all the same damn thing, and that developers are mythical creatures that pop apps out of a hat if they see enough forum posts and have leftover frog's breath and eye-of-newt from an iOS project.

    I think the real issue isn't so much that there's an artificially-imposed "partition," but that its baked into the hardware and software architecture of the device. My initial theory is that the "application memory" may be a special area of directly-addressable flash, while the "mass storage" (which requires an SDCard on some phones, is internal too on others) is accessed a bit more like a block I/O device (i.e. a disk drive).

    It may not be the simplest of options to walk through, but let's look at this block diagram of the BlackBerry Bold 9000: Blackberry 9000 Bold Block Diagram | cell phone diagram

    There are two interesting chips there. First, obviously, the CPU is a Marvel Tavor PXA930. Second, is this chip sitting next to it called an "MLC MoviNAND". This chip appears to combine high-performance NAND flash, eMMC (basically an embedded SDCard), and your usual RAM into a single chip.

    What that means is that these "partitioned memory spaces" are really completely separate bits if silicon inside the phone. You'll likely find similar in almost any BlackBerry you can find a block diagram of. (Some lack eMMC, though.)

    So the real issue is a combination of the hardware architecture, and the OS being designed around that architecture. Its also entirely possible that it actually runs apps directly from the high-performance NAND flash, instead of first copying them into RAM like a normal non-embedded computer might do. (But without being inside RIM, I really can't say.)

    Could all this be fixed going forward? Sure. It would take a redesign of the hardware architecture, and a redesign of the OS. This is probably all coming as part of the shift towards an all-new QNX-based product line next year.
    07-15-11 07:50 AM
  3. 1magine's Avatar
    Wow - allot of really intelligent speculation and conjecture. Appreciated. But like the delay in releasing these devices - most, myself included are no longer really interested in the reason.

    Application storage space is an issue. Period. Not for the world entire, but based on the success of other platforms and their application devlopment and sales - for most of the consumers out there. Other than this platform you can not buy a smartphone with less than 2 gigs of application memory. It as noted by a poster above that devlopers will adjust. WHY? Why would EA Sports, Rovio, USA Network, News12 (pick your locale), 'new developer guy' etc. decide to work that much harder to produce a BB application for an OS that will be largely replaced in less than a year? They don't now, they will not later. BB users will continue to get less apps of lesser quality.

    The screenie shows 200 megs of available app space. Since this space really acts more akin to a swap drive, this memory is much slower than saving to the other area of memory AND SLOWS THE DEVICE as it begins to fill. If this was really hard drive space - no slow down would occur with the other 7.- gigs of space left untouched. This is an issue discussed widely for more than 3 years on these forums, including part of many of Kevin's front page blogs. RIM's failure to adress this is an abortion of judgement of management.
    Rooster99 likes this.
    07-15-11 10:50 AM
  4. 1magine's Avatar
    As to the ring tones and alerts situation. I am not speaking of 2 sounds playing at once, which should now thankfull be fixed. I was speaking only of where the sounds play through. My short experience with the torch was that even with a headset plugged in, ringtones and alerts played through the device speaker. If that's not the case, in other's Torches, I am (not for the first or last time) misinformed.
    07-15-11 10:58 AM
  5. Rooster99's Avatar
    As to the ring tones and alerts situation. I am not speaking of 2 sounds playing at once, which should now thankfull be fixed. I was speaking only of where the sounds play through. My short experience with the torch was that even with a headset plugged in, ringtones and alerts played through the device speaker. If that's not the case, in other's Torches, I am (not for the first or last time) misinformed.
    I get ring tones through the headset. Alerts no.

    - R.
    07-15-11 02:33 PM
  6. anon(257429)'s Avatar
    8 gigs of device memory is again limited to media and document storage. Looks like only approx. 500 megs can be utilized for apps. Based on the latest screen shots provided in the new Torch video thread, looks like after the OS is fully loaded in, there is about 250 megs of app space left.

    I know that CB Kevin and an army of others have been calling for RIM remove the parrtition as app space is far more important than segregated media storage.

    I'm dissapointed. There is a saying amongst many that actions speak louder than words. In my opinion, while RIM is now saying they get it, and understand the current marketplace and want to deliver a modern device, and build up BB App world with feature rich applications and Open GL games; their decision to segregate memory - limiting application memory to about 500 megs, says differently.

    Now, I've heard from others this was not the case, that the partition was removed. But the only evidence I have seen, says the partition is still up.

    I think this is a colossal mistake. What do you think?
    Its because its still OS 6.0 OS7.0 (6.1) is a incremental upgrade. Updated icons and more apis for compasses, nfc etc. The file system is still old software.

    Now that I think about it, i am scared that memory leaks, battery pulls, battery pulls for app removals will still occur. The hardware has changed but not the software.
    07-16-11 12:04 AM
  7. anon(257429)'s Avatar
    I don't see how you can come to that conclusion. Java runtimes are generally dynamic: there is a class loader that loads classes as needed, and only when needed. I have seen apps that cause class loader exceptions when run: this implies that their classes are only loaded when the app is executed. The reason why you sometimes need to reboot has to do with persistent data. Apps that don't use persistent storage do not need a reboot when you delete them.
    Restart your BB, once its starts up... Look @ your logs. It will show you all applications, even the ringtones are pre loaded.

    Every app you load on a BB needs a reboot after you delete it. Every single one.
    07-16-11 12:13 AM
  8. market58's Avatar
    i totally agree. if my Storm memory dropped below 60 megs the phone became unstable and buggy. Subsequent calls to Verizon advise me to free up memory. I want to be able to utilize as much memory for apps as possible. What good is a large memory without the ability to use it.
    07-16-11 05:26 AM
  9. cwong15's Avatar
    Restart your BB, once its starts up... Look @ your logs. It will show you all applications, even the ringtones are pre loaded.

    Every app you load on a BB needs a reboot after you delete it. Every single one.
    If you are talking about those "CMM: <app name> no sig..." messages in the event log, that's just the OS verifying code signatures. It does not imply that the classes are actually loaded and resident. As I said before, I've seen apps that install fine but have loader verification errors when I actually run them, implying that the loading is done when you run the app, not at boot time. Only apps that have the run on startup flag set will run on bootup.

    It is not true that every app needs a reboot to delete. I have written apps that do not need a reboot to delete. I have also written apps that do. I know the difference because I know what went into my code. I can point you at the relevant developer doc if you like. The short explanation is that use of persistent storage sometimes requires a reboot for app uninstall. Apps that don't use persistent storage normally would not need a reboot for uninstall.

    If you monitor RAM (not flash) usage -- a third party app like my MemStats will show RAM stats -- you will see that when you run an app with a lot of code the footprint jumps several MB and there is a noticeable delay in startup. This is not consistent with a preloaded app. There is nothing in a BB's behavior that suggests that all apps are preloaded at boot time.
    07-17-11 08:51 AM
  10. 1magine's Avatar
    According to Just got my 9810 upgraded - BlackBerry Forums at CrackBerry.com

    The Torch 2 is actually showing less available app memory with the same number of applications installed, than it's predecessor.

    If you do not think this is an absolute failure of either engineering and/or will of management to address the OS's structural limitations - than allow me to sell you a slightly used NYC Bridge (all the toll money you could ever use), by quit claim deed of course.
    07-17-11 09:11 AM
  11. SugarMouth's Avatar
    Frankly I am more concerned about having enough RAM than memory for apps. I will be just fine with 250mb for apps with my current usage since I'm not into games.
    07-17-11 11:28 AM
  12. anon(257429)'s Avatar
    If you are talking about those "CMM: <app name> no sig..." messages in the event log, that's just the OS verifying code signatures. It does not imply that the classes are actually loaded and resident. As I said before, I've seen apps that install fine but have loader verification errors when I actually run them, implying that the loading is done when you run the app, not at boot time. Only apps that have the run on startup flag set will run on bootup.

    It is not true that every app needs a reboot to delete. I have written apps that do not need a reboot to delete. I have also written apps that do. I know the difference because I know what went into my code. I can point you at the relevant developer doc if you like. The short explanation is that use of persistent storage sometimes requires a reboot for app uninstall. Apps that don't use persistent storage normally would not need a reboot for uninstall.

    If you monitor RAM (not flash) usage -- a third party app like my MemStats will show RAM stats -- you will see that when you run an app with a lot of code the footprint jumps several MB and there is a noticeable delay in startup. This is not consistent with a preloaded app. There is nothing in a BB's behavior that suggests that all apps are preloaded at boot time.
    Whst are you apps on BB that you have written? I want to try this out.

    You seem to be comparing java on a computer instead of a BB phone.

    The BB java version is proprietary.

    I would believe you if what people have witness didnt contradict that. The app occupies the same memory that app needs to run. If the App is 2mb, and it needs 4mb to run your memory goes down 4mb + 2mb the app the space is occupying. If i have 10 apps @ 2mb thats 20mb right?

    And lets say i have 40mb of clear, untouch, unused memory on my phone, by your explanation when i download 20mb of apps, i should have 40 mb at reboot no matter what? right? And when i open all those apps thats when the memory starts to go down?
    07-17-11 11:39 AM
  13. cwong15's Avatar
    Whst are you apps on BB that you have written? I want to try this out.

    You seem to be comparing java on a computer instead of a BB phone.

    The BB java version is proprietary.

    I would believe you if what people have witness didnt contradict that. The app occupies the same memory that app needs to run. If the App is 2mb, and it needs 4mb to run your memory goes down 4mb + 2mb the app the space is occupying. If i have 10 apps @ 2mb thats 20mb right?

    And lets say i have 40mb of clear, untouch, unused memory on my phone, by your explanation when i download 20mb of apps, i should have 40 mb at reboot no matter what? right? And when i open all those apps thats when the memory starts to go down?
    You can find most of my apps in the link in my sig. The not-very-useful ExtraLight app will install and uninstall without requiring a reboot, because it uses no persistent storage.

    There is no contradiction between what I said and what you observe in memory usage. Don't just say "memory": you need to be specific. My original post was in response to someone claiming that all apps were loaded in RAM. "Application memory" is not RAM: it's a special area of flash memory. The memory that your BB reports is this flash memory. RAM is something else. RAM stats are not reported by your BB, unless you use a 3rd party app or enable the engineering screen. If you install an app, you should see your application memory (flash) drop, but that has no correlation to RAM usage.

    By the way, don't assume RIM's Java is proprietory. If you look at the About screen in the Options app, it will indicate that the BB is using Sun's JVM. This is not desktop Java, but the J2ME JVM.
    07-18-11 10:22 AM
  14. iN8ter's Avatar
    I have one question, what happens if you have apps stored on the memory card and if you remove it and insert it into another android phone? Do the apps run?

    Posted from my CrackBerry at wapforums.crackberry.com
    No, that's one big issue. However if the device is partitioned similarly to Samsung Galaxy S phones you can move this stuff to the INTERNAL SD card, which is always assumed to be there (and indeed, always is) and not the External SD card.

    RIM simply needs a unified storage model similar to iOS, WP7, and WebOS. Even Android's partitioning method is from the 90s and terribad, IMO.

    Installing Apps to Removable Storage is only useful if it is done similarly to Windows Mobile - that is, the entire App is installed there (Apps that are services, etc. aren't allowed to be installed there in Windows Mobile). On Android moving an App to SD can result in anything from 10-90% of the App being moved. The Assumption that you can move a few big apps to the SD Card (some of them listed like "Email" cannot even be moved, that is a stock app unless I'm missing something) can free up 100 MB space is chuckle-inducing. If you get the right combination of apps you can end up only freeing 20 MBs. That's why App2SD on Android is a big of a joke, and every high end Android phone comes with more than enough App Storage (2GB with 1.5GB+ free after first boot) so that people don't have to use it.

    Android App2SD is for low end and older Android devices that either don't have an Internal SD Card that Apps can load data to, or have No Internal SD Card and very low on-device App Storage (HTC Aria 320 MB App Storage Free vs. Galaxy S 1.67 GB App Storage Free after first boot).

    Android Apps CAN download data to an External SD card. But the quality of that card is always up in the air so there can be random performance issues or crashes if the card isn't great and/or is failing. Lots of people buy large Class 2 SD Cards because they're cheap, and that can cause some issues with certain types of data (large textures and video files, e.g.). OEMs almost always use at least Class 4 Cards as Internal Storage, provided they aren't using NAND which is clearly superior.

    EDIT: Also, Blackberries do use Sun's J2ME (they're free to develop whatever proprietary APIs on top of it, the same way you can develop your own [proprietary] APIs on desktop Java i.e. SWT vs. Native SWING libraries). Android DOES use a proprietary JVM-type architecture, and that's why they're getting sued - not RIM. Sun, especially, was not cool with people making similar/imitating products and calling it remotely Java. Remember J++?
    Last edited by N8ter; 07-19-11 at 07:14 AM.
    07-19-11 07:00 AM
  15. belfastdispatcher's Avatar
    No, that's one big issue. However if the device is partitioned similarly to Samsung Galaxy S phones you can move this stuff to the INTERNAL SD card, which is always assumed to be there (and indeed, always is) and not the External SD card.

    RIM simply needs a unified storage model similar to iOS, WP7, and WebOS. Even Android's partitioning method is from the 90s and terribad, IMO.

    Installing Apps to Removable Storage is only useful if it is done similarly to Windows Mobile - that is, the entire App is installed there (Apps that are services, etc. aren't allowed to be installed there in Windows Mobile). On Android moving an App to SD can result in anything from 10-90% of the App being moved. The Assumption that you can move a few big apps to the SD Card (some of them listed like "Email" cannot even be moved, that is a stock app unless I'm missing something) can free up 100 MB space is chuckle-inducing. If you get the right combination of apps you can end up only freeing 20 MBs. That's why App2SD on Android is a big of a joke, and every high end Android phone comes with more than enough App Storage (2GB with 1.5GB+ free after first boot) so that people don't have to use it.

    Android App2SD is for low end and older Android devices that either don't have an Internal SD Card that Apps can load data to, or have No Internal SD Card and very low on-device App Storage (HTC Aria 320 MB App Storage Free vs. Galaxy S 1.67 GB App Storage Free after first boot).

    Android Apps CAN download data to an External SD card. But the quality of that card is always up in the air so there can be random performance issues or crashes if the card isn't great and/or is failing. Lots of people buy large Class 2 SD Cards because they're cheap, and that can cause some issues with certain types of data (large textures and video files, e.g.). OEMs almost always use at least Class 4 Cards as Internal Storage, provided they aren't using NAND which is clearly superior.

    EDIT: Also, Blackberries do use Sun's J2ME (they're free to develop whatever proprietary APIs on top of it, the same way you can develop your own [proprietary] APIs on desktop Java i.e. SWT vs. Native SWING libraries). Android DOES use a proprietary JVM-type architecture, and that's why they're getting sued - not RIM. Sun, especially, was not cool with people making similar/imitating products and calling it remotely Java. Remember J++?
    I'm not too knowledgeable about all this but after witnessing some serious lag on my mate's LG Optimus 2X dual core, Android must be quite inefficient with apps as I could run more apps on my 9700 then what he had opened on his LG without any lag.
    On a touch screen lag is even more accentuated as you don't know for sure if it's lag or just an unregistered touch command.

    Posted from my CrackBerry at wapforums.crackberry.com
    07-19-11 07:33 AM
  16. Nbpuli's Avatar
    Have we we heard anything new regarding OS 7 and app memory partitioning? This is a huge issue for me as inadequate app memory has been the bane of my Storm 9530 ( and is not any better on Storm2)
    08-04-11 09:11 AM
66 123
LINK TO POST COPIED TO CLIPBOARD