Geheugenbeheer: 64mb, waarvan 51 beschikbaar

[dirk]

Hm 4 Mb is nog niet 13. Is die heap dus ook niet alles. Kun je het niet
zien met zo'n mem-progje van tealpoint.com?

Edit: tealmembrain heet het.
Het dateert wel van 2001, dus kweet niet of het draait op een TT of TC
Je kunt er wel van alles mee zien.

[patrickl]

Hoezo 4MB? De Clie NX heeft inderdaad een 4MB heap. De Tungsten-C heeft een 12MB heap. Althans dat zou Arent kunnen checken met Memory Hog.

Tealmembrain zou inderdaad ook kunnen. Die data heap categorie zou dan de Dynamic heap size aangeven. Of een pop-up gaat werken in OS5 weet ik alleen niet. Memory Hog heb ik zelf getest en dat werkte dus prima en gaf netjes de juiste heap size aan.

[jean-paul]

Tungsten|T
Total Storage: 14335 K
Free Storage: 4100 K
Total Dynamic: 804 K
Free Dynamic: 635 K

Tungsten|C
Total Storage: -13313 K (kan blijkbaar geen 64MB aan)
Free Storage: -17526 K (idem)
Total Dynamic: 12288 K
Free Dynamic: 12205 K

Zire71
Total Storage: 14207 K
Free Storage: 4570 K
Total Dynamic: 1024 K
Free Dynamic: 929 K

- jp

[patrickl]

Ah cool, jij hebt ze natuurlijk ook weer allemaal liggen Bedankt.

12MB Dynamic heap dus.

(Bij die negatieve getallen moet je even 64k optellen. Blijkbaar hebben ze per ongeluk een integer gebruikt)

De vraag blijft dan hooguit nog waarom zo veel. NetFront zou wel liever meer dan 4MB hebben, maar dat zit niet op de Tungsten-C toch? Zit er iets speciaals qua software op? Of zijn ze gewoon voorbereid op de toekomst.

[jean-paul]

Tungsten|C
WiFi Setup, Versamail (huge!), Mergic VPN (plus SSL-functionaliteit), Web Browser Pro 2.0 (weer geen Netfront), Docs To Go (alle componenten) en een Photo-applicatie. Dat is allemaal 'ingebakken'.

Overigens is Sony begonnen met deze trend. Palm doet het bundelen in ROM van applicatiesvolgens mij pas met deze twee laatste modellen (Zire71/Tungsten|T). D'r is wat voor te zeggen, maar doe er dan in ieder geval een programmaatje bij waarmee je bepaalde onderdelen kunt verwijderen.

- jp

[patrickl]

Bundelen in ROM? Zit die software allemaal in de ROM? Aan de ene kant wel handig (hou je meer RAM geheugen vrij), maar met het oog op updates nou weer niet echt nee.

Sony levert overigens alleen de echt standaard applicaties (datebook etc) en de eigen software (zeg maar, Clie multimedia programma's) in ROM. Geen third party software. NetFront en PicselViewer vreten gewoon 3MB a 4MB van je RAM op.

Ik denk dat Sony ook wel moest. Opgeteld zijn die Sony applicaties iets van 4MB a 5MB groot. Als je dat ook nog eens in je 11MB moet gaan proppen dan worden de gebruikers wel heel erg nijdig. Voor Palm is er toch niet echt een noodzaak om het in ROM te zetten? 51MB is toch zat om zelf wat in te zetten lijkt me.

Uiteindelijk toch jammer dat ze dat gedaan hebben, want met Jackflash kun je wel zelf applicaties in het ROM zetten, maar de standaard software kun je niet verwijderen. Hadden ze al die mutimedia apps zelf installeerbaar gemaakt in flash ROM dan had dat geheuegen ook voor iets anders gebruikt kunnen worden.

Is de Tungsten-C/Zire 71 overigens wel Jacksprat compatible? Dat is met de Clie NX inderdaad niet zo. Dat is wel knap irritant. De nieuwe versie van de Flash Player (met MP3 support) en de Clie Files (met ZIP file support) staan nu in mijn RAM geheugen in plaats van in de ROM waar ze zouden moeten staan. Totaal 1MB

Ik zie trouwens in het lijstje dat je noemt nou ook niet echt iets dat 12MB dynamic heap nodig zou hebben. Of is Web Pro inmiddels proxyless?

[r. dohmen]

De vraag is nu of je de grootte van het dynamisch geheugen kunt aanpassen veranderen. Met - als je het verkleind - het risico dat sommige programma's niet genoeg ruimte hebben om te werken.
Ik krijg het gevoel dat dat niet kan. Dit lijkt een beetje op wat vroeger memorymapping heette. Een deel van het werkgeheugen werd afgebeeld op een grafische kaart oid. Of (wat ook kon) een deel van het BIOS werd in RAM geladen zodat het allemaal wat sneller werkte.

In dit geval wordt dan software uit ROM in RAM gekopieerd (bij een harde reset ). De ruimte die daarvoor beschikbaar is zou bij het compileren van het OS gekozen kunnen worden, net als de set bestanden die in die ruimte moeten.

Die ROM-software zou dan bijvoorbeld in het bovenste deel van het ROM kunnen zitten, wat na het kopieren door het OS gemaskeerd wordt; je hebt bijvoorbeeld 32 Mb, in de bovenste 16 MB staat deze software.Na het kopieeren staat het OS alleen het adresseren van de onderste 16 Mb toe.

Ik weet dus niet of het echt zo werkt (ik heb documententie die dat kan bevestigen nog nooit gezien) maar het zou niet de eerste keer in de computergeschiedenis zijn, dat het zo werkt.

[patrickl]

Je kunt die grootte inderdaad niet aanpassen. Zelfs met de simulator krijg je een hard reset als je dat doet.

Het ROM geheugen heeft overigens helemaal niets met dynamic heap te maken. Ik snap niet hoe mensen steeds op die link komen. ROM is ROM en RAM is verdeeld in "File Storage" en "Dynamic Heap".

Het file storage deel is voor het opslaan van PDBs PRCs etc (zeg maar de hard disk van een PC) en de dynamic heap is voor het opslaan van tijdelijke data (zeg maar het RAM geheugen van de PC).

[r. dohmen]

Citaat:

Op 16-05-2003, om 12:09 heeft patrickl dit gezegd in bericht #26

Ik zie trouwens in het lijstje dat je noemt nou ook niet echt iets dat 12MB dynamic heap nodig zou hebben. Of is Web Pro inmiddels proxyless?

ja, dat is zo. Het blijft natuurlijk vreemd. Onder OS4/Dragonball kon een applicatie gewoon in het ROM staan en gestart worden alsof het in RAM stond. Het lijkt er op dat dat niet meer voor alle programma zo is. Misschien ligt de reden wel in het ARM-platform? Op PPC's zie je ook zo'n soort geheugen gebruik, zoals al eerder werd gezegd.. Misschien zijn bepaalde soorten van adressseren niet meer mogelijk; ik denk dan aan een programma in ROM dat databestanden in RAM wil gebruiken?

[MendriX]

Citaat:

Op 16-05-2003, om 12:13 heeft r. dohmen dit gezegd in bericht #27 Die ROM-software zou dan bijvoorbeld in het bovenste deel van het ROM kunnen zitten, wat na het kopieren door het OS gemaskeerd wordt; je hebt bijvoorbeeld 32 Mb, in de bovenste 16 MB staat deze software.Na het kopieeren staat het OS alleen het adresseren van de onderste 16 Mb toe.

Maskeren? Als ze zoiets doen is het waarschijnlijker dat het gecomprimeerd in het OS zit of in ieder geval in ROM, wat dan UITPAKT naar RAM. Lijkt me allemaal veel 'gedoe'. Enige reden die ik hiertoe zou kunnen verzinnen is dat er bijv. maar 4MB ROM beschikbaar is voor die extra software, maar dat het uitgepakt maar liefst 7 in beslag neemt o.i.d.. Anders zouden ze het gewoon uit ROM laten draaien, want dat is snel zat.

[r. dohmen]

Citaat:

Op 16-05-2003, om 12:19 heeft patrickl dit gezegd in bericht #28
Het file storage deel is voor het opslaan van PDBs PRCs etc (zeg maar de hard disk van een PC) en de dynamic heap is voor het opslaan van tijdelijke data (zeg maar het RAM geheugen van de PC).

Dat is idd niets nieuws, dat onder oudere OS-en ook al zo. Maar in een eerdere bericht (contekst) wordt op z'n minst de suggestie gewekt dat er wel bestanden in staan. Ik kan het niet controleren.
Als het zo is als jij nu schetst, is de scheiding van die twee geheugenbestemmingen nu gewoon wat harder dan vroeger.
Wat daar dan de reden van is is dan nog niet duidelijk: is het noodzakelijk op het processorplatform? Maak je er het OS stabieler/veiliger mee?

[jean-paul]

Citaat:

Op 16-05-2003, om 12:09 heeft patrickl dit gezegd in bericht #26
Bundelen in ROM? Zit die software allemaal in de ROM? Aan de ene kant wel handig (hou je meer RAM geheugen vrij), maar met het oog op updates nou weer niet echt nee.

Naja, updates kun je natuurlijk nog steeds in RAM installeren.

Citaat:

Ik denk dat Sony ook wel moest. Opgeteld zijn die Sony applicaties iets van 4MB a 5MB groot. Als je dat ook nog eens in je 11MB moet gaan proppen dan worden de gebruikers wel heel erg nijdig. Voor Palm is er toch niet echt een noodzaak om het in ROM te zetten? 51MB is toch zat om zelf wat in te zetten lijkt me.

Ik weet niet zeker of het in ROM staat, maar na een harde reset heb ik in ieder geval de beschikking over deze programma's. De opmerking van r.dohmen hieronder klinkt wat dat betreft zeer aannemelijk.

Ik lees trouwens net op de Brayder-website dat het Expansion ROM heet en dat het inderdaad is aan te passen: http://www.brayder.com/products/romcrafter.html. Helaas niet voor Sony's beschikbaar en aangezien het bedoeld is om PalmOS-devices beheersbaar te maken voor bedrijven ook een beetje prijzig: $ 500,- voor de software plus $5 per device.

Citaat:

Is de Tungsten-C/Zire 71 overigens wel Jacksprat compatible? Dat is met de Clie NX inderdaad niet zo.

Nee, nog niet. Een OS5-versie van JackSprat wordt nog steeds verwacht. JackFlash Light geeft voor de Tungsten|C 1792 K vrije Flash en de Zire71 is (blijkbaar) nog niet compatible met JackFlash Light. Ik krijg in ieder geval de melding dat er geen Flash beschikbaar is (ben de specs even vergeten).

Citaat:

Ik zie trouwens in het lijstje dat je noemt nou ook niet echt iets dat 12MB dynamic heap nodig zou hebben. Of is Web Pro inmiddels proxyless?

Ja, die is gelukkig wel proxyless. Dat dan weer wel ((c) Hans Teeuwen). Helaas hebben ze niet de drie 'views' van NetFront of iPanel overgenomen (WYSIWYG, shrink-to-fit en miniature).

[r. dohmen]

Citaat:

Op 16-05-2003, om 12:24 heeft MendriX dit gezegd in bericht #30


Maskeren? Als ze zoiets doen is het waarschijnlijker dat het gecomprimeerd in het OS zit of in ieder geval in ROM, wat dan UITPAKT naar RAM. Lijkt me allemaal veel 'gedoe'. Enige reden die ik hiertoe zou kunnen verzinnen is dat er bijv. maar 4MB ROM beschikbaar is voor die extra software, maar dat het uitgepakt maar liefst 7 in beslag neemt o.i.d.. Anders zouden ze het gewoon uit ROM laten draaien, want dat is snel zat.

Lijkt me gemakkelijk te controleren. Overigens zegt Patrick dat er helemaal geen programma in kunnen staan. Iemand met een OS5 machine kan dat zo checken.

[patrickl]

Contekst heeft gewoon niet goed gekeken. Dat werd hem ook al uitgelegd door Dirk en koekiemonster.

Het is helemaal niet anders dan vroeger. Het is alleen groter geworden. Zoals Arent al uit de OS3 beschrijving had gehaald was het vroeger 96kB of 256kB ofzo. Dat zag je dus niet verdwijnen. Palm hoopt nu blijkbaar dat er complexere applicaties gaan komen en die hebben meer geheugen nodig.

Kijk ook naar die staatjes van JP. De dynamic heap is gewoon leeg.

Tsjonge dat valt nog niet mee om dit er door te krijgen zeg. Bijna net zo moeilijk als om de vooroordelen tegen Sony uit de wereld te helpen. Alhoewel Sony hard zijn best doet om weer een hele nieuwe serie vooroordelen de wereld in te helpen.

[MendriX]

Citaat:

Op 16-05-2003, om 12:31 heeft r. dohmen dit gezegd in bericht #33 Overigens zegt Patrick dat er helemaal geen programma in kunnen staan. Iemand met een OS5 machine kan dat zo checken.

Normaal gesproken wordt een heap (zo ook stack) gebruikt voor geheugen aanvragen van software om DATA in de plaatsen, geen code. Maar ik weet niet hoe dit bij PalmOS zit. Ik kan me voorstellen dat je zoiets invoert als een code-heap, voor swappen van code/programmatuur.

[jean-paul]

Uit de whitepaper van ROMCrafter (zie link hierboven).

Citaat:

PalmOS Memory Architecture
Applications and data can be stored in four distinct areas, on a PalmOS device, each with their own advantages and disadvantages. A PalmOS device has a different design
Brayder Technologies Inc. ROM Crafter™ philosophy than a typical computer. This reflected in how applications and data are stored and accessed.
The primary storage areas are RAM, System ROM and Expansion ROM. Each of these areas can store and allow direct access to applications and data. The fourth storage area is an expansion card. Expansion cards allow applications and data to be stored, but they typically require items to be moved to RAM before they can be directly accessed.

• RAM is where most add-on applications are stored and where all user-generated data is stored. The main feature of RAM is that items are directly modifiable by the PalmOS. The disadvantage of this storage area is that its contents will be lost if a battery failure or a hard reset should occur.
• System ROM is the storage area where the PalmOS itself is stored, along with all of the built-in applications. The main features of the System ROM are that contains the core operating system and its contents are not lost on a battery failure. The disadvantage of this storage area is that it is not normally modifiable. Items stored in the System ROM are not updateable.
• Expansion ROM is a new storage area supported by ROM Crafter. It uses the remaining area of the ROM that is not used by the System ROM. On devices that use Flash ROM, it can be used to store applications and databases. The contents of the Expansion ROM will not be lost if a battery failure or hard reset occurs. Files can be moved in and out of the Expansion ROM using the ROM Crafter libraries. The only disadvantage of this storage area is that it is not directly modifiable by the PalmOS. Modifiable items must be updated in RAM and then moved to the Expansion ROM.
• Expansion cards are used as a secondary storage area by the PalmOS. Files can be moved between RAM and an expansion card, and PalmOS applications can be modified to use expansion cards for data storage. The PalmOS Launcher provides a way of running applications from an expansion card by transparently copying it into RAM and then running it from there. The main advantage of expansion cards is their storage size; they can significantly add to the storage capabilities of a PalmOS device. The main disadvantage of expansion cards is that they work differently than the other storage areas and cannot be used transparently to expand the device. Another disadvantage of expansion cards is that they can be removed, eliminating any guarantee of availability.

[MendriX]

Citaat:

Op 16-05-2003, om 12:34 heeft patrickl dit gezegd in bericht #34
Het is helemaal niet anders dan vroeger. Het is alleen groter geworden.

Lijkt me ook het meest waarschijnlijke, maar ach, beetje speculeren scherpt het brein. Ik vind overigens van paar honder kB naar een tiental MB een AANZIENLIJKE groei. Is het niet zo dat de heap altijd dynamisch groeit/krimpt? Ik kan me niet voorstellen dat een fixed size slim zou zijn voor een OS? Als je heavy DB's draait worden die al gauw erg groot. Is misschien de initiele size van de heap zo groot geworden? Je kan toch zeker wel een database van 2 MB bewerken op een M515? Of werk je dan rechtstreeks in het bestand in het geheugen? Ik vind het dan geen heldere scheiding tussen dataebestanden/datain je heap/software.

[patrickl]

Ja en dan nog een uitleg van de RAM architectuur:

Citaat:

The Palm OS divides the total available RAM store into two logical areas: dynamic RAM and storage RAM. Dynamic RAM is used as working space for temporary allocations, and is analogous to the RAM installed in a typical desktop system. The remainder of the available RAM on the card is designated as storage RAM and is analogous to disk storage on a typical desktop system.

The entire dynamic area of RAM is used to implement a single heap that provides memory for dynamic allocations. From this dynamic heap, the system provides memory for dynamic data such as global variables, system dynamic allocations (TCP/IP, IrDA, and so on, as applicable), application stacks, temporary memory allocations, and application dynamic allocations (such as those performed when the application calls the MemHandleNew function).

The entire amount of RAM reserved for the dynamic heap is always dedicated to this use, regardless of whether it is actually used for allocations. The size of the dynamic area of RAM on a particular handheld varies according to the OS version running, the amount of physical RAM available, and the requirements of pre-installed software such as the TCP/IP stack or IrDA stack. Table 5.1 provides more information about the dynamic heap space that currently available combinations of OS and hardware provide.

Palm OS® Programmer's Companion Memory Architecture

[MendriX]

Vooral laatste van Patrick is interessant. Ik vind het nogal 'stug' van het OS om fixed size dynamic heap te gebruiken. Kan me voorstellen dat je makkelijk tegen de grenzen aan loopt afhankelijk van je type software en programmeertechnieken. (Intensief recursief priemgetallen proeven zal er niet bij zijn met 800kB heap.)

[patrickl]

Citaat:

Op 16-05-2003, om 12:39 heeft MendriX dit gezegd in bericht #37


Lijkt me ook het meest waarschijnlijke, maar ach, beetje speculeren scherpt het brein. Ik vind overigens van paar honder kB naar een tiental MB een AANZIENLIJKE groei. Is het niet zo dat de heap altijd dynamisch groeit/krimpt? Ik kan me niet voorstellen dat een fixed size slim zou zijn voor een OS? Als je heavy DB's draait worden die al gauw erg groot. Is misschien de initiele size van de heap zo groot geworden? Je kan toch zeker wel een database van 2 MB bewerken op een M515? Of werk je dan rechtstreeks in het bestand in het geheugen? Ik vind het dan geen heldere scheiding tussen dataebestanden/datain je heap/software.

Een database is een bestand. Die benader je via een andere API. het gaat meer om data die je normaal gesproken in de RAM van je PC hebt staan. Bijvoorbeeld bij een web browser alle plaatjes die je aan het verkleinen bent en de video buffer die je aan het opbouwen bent om het hele beeld te laten zien. Een Clie NX scherm in 16 bits kleurdiepte is 300kB groot. Als je er daar een paar van nodig hebt gaat het hard.