On Friday, August 1, 2003, at 02:57  AM, Andreas Raab wrote:

> John,
>
> Here's a thought on the "root bit problem" that might be worthwhile to  
> check
> out. I _think_ it is the case that the root bit is only set for the  
> active
> context upon save. If that were true (we'd have to check a bunch of  
> images
> all the way back) we could use the root bit of the active context to  
> decide
> whether to do any root-bit cleaning as well as the external primitive
> flushing. This would allow us to bring the startup overhead down to  
> exactly
> zero ;-) Wanna give it a try?
>
>> Yes, but that wouldn't work because we can't say where the
>> image comes from, so I can' say they are clean.

Well I'm looking to see where that one object with the root bit set  
comes from. A quick look didn't tell me.
Some in or after the fullGC I'd guess.

I'll note one of the things that happens is that we could totalObjects  
to decide how to size the forwarding table.
That would require a change, either store that info on the save, or do  
something on the startup.

>
>> That I'm looking at, we do page all that memory in because we
>> read the file into the first chunk of it.
>
> A worthwhile thing to try might be touch (e.g., write) all of the  
> memory
> pages that you read into, before doing the actual read. This should  
> ensure
> that the memory isn't mapped during the read and should give you a  
> pretty
> good measurement if it's really the mapping that hurts (e.g.,  
> comparing the
> "time-to-touch" with the "time-to-read").

Mmm there are some calls to indicate how memory will be used, or if it  
should
be paged in. I'll look further.
--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===