On Fri, 2010-10-15 at 17:21 -0700, Tom Rushworth wrote:
> I see.  Perhaps it's time to dig into the VM and see if you can't make
> the GC cough up info about how much space it thinks the VM is really
> using.  Not nearly as easy as a "ps" though...

Which is what SmalltalkImage (as of 3.9.1-7075, the www.squeak.org
image, the class name may vary)>>vmParameterAt: seems to provide, quote:

...[the argument] is a positive integer corresponding to one of the VM's
internal parameter/metric registers.  Answer with the current value of
that register.
	Fail if parameterIndex has no corresponding register.
	VM parameters are numbered as follows:
		1	end of old-space (0-based, read-only)
		2	end of young-space (read-only)
		3	end of memory (read-only)
		4	allocationCount (read-only)
		5	allocations between GCs (read-write)
		6	survivor count tenuring threshold (read-write)
		7	full GCs since startup (read-only)
		8	total milliseconds in full GCs since startup (read-only)
		9	incremental GCs since startup (read-only)
		10	total milliseconds in incremental GCs since startup (read-only)
		11	tenures of surving objects since startup (read-only)
		12-20 specific to the translating VM
		21	root table size (read-only)
		22	root table overflows since startup (read-only)
		23	bytes of extra memory to reserve for VM buffers, plugins, etc.

		24	memory threshold above which shrinking object memory (rw)
		25	memory headroom when growing object memory (rw)
		26  interruptChecksEveryNms - force an ioProcessEvents every N
milliseconds, in case the image  is not calling getNextEvent often (rw)
		27	number of times mark loop iterated for current IGC/FGC (read-only)
includes ALL marking
		28	number of times sweep loop iterated  for current IGC/FGC
(read-only)
		29	number of times make forward loop iterated for current IGC/FGC
(read-only)
		30	number of times compact move loop iterated for current IGC/FGC
(read-only)
		31	number of grow memory requests (read-only)
		32	number of shrink memory requests (read-only)
		33	number of root table entries used for current IGC/FGC (read-only)
		34	number of allocations done before current IGC/FGC (read-only)
		35	number of survivor objects after current IGC/FGC (read-only)
		36  millisecond clock when current IGC/FGC completed (read-only)
		37  number of marked objects for Roots of the world, not including
Root Table entries for current IGC/FGC (read-only)
		38  milliseconds taken by current IGC  (read-only)
		39  Number of finalization signals for Weak Objects pending when
current IGC/FGC completed (read-only)
		40  VM word size - 4 or 8 (read-only)

this function maps to primitive 254.

In this thread I have been quoting figures reported by parameters 2 and
3 with, I have assumed, 3 having some relevance to the RSS.

> Which means that part of the information your really want may be paged
> out and so not counted :(.

Sure, but that's not entirely relevant to my question, at least one of
them anyway, which is why there is so much discrepancy between what from
the image seems to be the memory usage and what the operating system
reports it as.  The answer of course is likely, at least in part, that
the value of vmParameter 3 is being misinterpreted and that this is at
best part of the right number, perhaps combined with the values of some
of the other parameters.

I started this thread looking for pointers to what could be the cause of
the unexpected amount of memory being used by the website process.  At
the same time this lead to other curious things and perhaps it would be
best to leave those out of the discussion for now in preference to the
issue at hand as to what we can due to decrease the resource cost of the
website process serving www.squeak.org.

> > 
> > Ken
> > 
> 
> --
> Tom Rushworth

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20101015/d9bc1c49/attachment.pgp