|
|
Andrés Garagiola schrieb am 30.04.2007 15:59:
> I'm trying run an very simple vw application (a windows with an input
> text widget) on a pocket pc (Symbol PDT 8100). Some times the
> application not start because the memory is not sufficient and other
> times the application start but the windows not draw completely.
> It pocket PC have and Intel SA1110 @ 206MHz processador and 64 MB RAM,
> 32 MB ROM (Ample storage capacity for data and applications), do you
> know if it is sufficient for run an runtime image of vw 7.4? somebody
> install VW on a hardware like this?
It should be possible to run VisualWorks under these constraints. But
you have to make sure that your application respects the memory limits.
You probably don't have all of the 64 MB of RAM available for your
application. I assume that the operating system will want some of it for
itself. Try running your application on a system with more RAM and see
if it consumes more memory than you thought.
There is quite good documentation on VisualWorks memory management in
the doc and doc/TechNotes directories of the VW distribution. Have a
look at vwMemoryMgmt.pdf for details.
You will have to set the parameters of the MemoryPolicy and the
"ObjectMemory sizesAtStartup" such that memory consumption is reduced to
less than 64 MB. Also, it is a good idea to strip everything from the
image which isn't needed.
Here's what I would try:
- ObjectMemory sizesAtStartup
Leave them at the default settings, which are pretty small. If you have
more RAM than 64 MB, it's usually a good idea to increase some of them,
in particular the sizes of Eden and SurvivorSpace by something like 10.0
to 20.0, to reduce scavenging and gain speed (you wouldn't believe how
much can be gained that way). But in your case, start small and make it
run before making it fast.
- MemoryPolicy
ObjectMemory currentMemoryPolicy
memoryUpperBound: 48000000; "Never use more than ca. 48 MB"
growthRegimeUpperBound: 45000000; "Prefer garbage collection over
growth starting at ca. 45 MB"
preferredGrowthIncrement: 1000000; "Default, grow memory in chunks
of 1 MB"
freeMemoryUpperBound: 3000000. "If free memory in the image exceeds
3 MB, return it to the operating system. Don't make this
smaller than or equal to preferredGrowthIncrement, otherwise
you risk VM crashes (at least in 7.4)."
The actual values of memoryUpperBound and growthRegimeUpperBound will
depend on how much RAM is really available. growthRegimeUpperBound
should be less than (memoryUpperBound - preferredGrowthIncrement). I
usually use (memoryUpperBound - (3 * preferredGrowthIncrement)).
MemoryPolicy contains some old code from VW 3.x which is obsolete. You
might want to implement your own subclass of MemoryPolicy and override
the method primeThreadedDataList such that it does nothing but return
true. The logic behind this method is based on a free-list
implementation which has been replaced by other data structures since VW
5i. In its current state, the method reserves a large chunk of memory
(25k) for future use each time it is executed, but this future use never
happens. It's not a real memory leak, as the effect goes away upon
memory compaction, but under tight constraints, it's making things
worse. As an alternative to reimplementing the method, set the parameter
threadedDataIncrement to a very small value:
ObjectMemory currentMemoryPolicy threadedDataIncrement: 1.
HTH,
Joachim Geidel
|
Locked
