Re: vfs, ubc and pre-fetching on snow leopard
Re: vfs, ubc and pre-fetching on snow leopard
- Subject: Re: vfs, ubc and pre-fetching on snow leopard
- From: Joel Reymont <email@hidden>
- Date: Mon, 9 Nov 2009 15:03:19 +0000
On Nov 9, 2009, at 4:55 AM, Eric Gouriou wrote:
Is Firefox/Minefield still single-threaded by the time your
measurements are
captured ? If not this could also lead to run-to-run variations.
I'm only looking at the differences in the dyld stage, usually the
first 13-20 page-ins.
Do you see that order being stable across all runs ?
Not really. I'll investigate the Firefox code but I would also like to
figure out the variations in the dyld portion of the page-ins, before
library initializers run.
Following are 3 complete samples of dyld-related page-ins. I
determined that these are the product of pre-initialization dyld work
by looking at the user-space stack trace, e.g. this is before
initializers
dyld`ImageLoaderMachOCompressed::rebase
(ImageLoader::LinkContext const&)+0x63
dyld`ImageLoader::recursiveRebase
(ImageLoader::LinkContext const&)+0x67
dyld`ImageLoader::recursiveRebase
(ImageLoader::LinkContext const&)+0x45
dyld`ImageLoader::link(ImageLoader::LinkContext const&,
bool, bool, ImageLoader::RPathChain const&)+0x89
dyld`dyld::link(ImageLoader*, bool,
ImageLoader::RPathChain const&)+0x76
dyld`dyld::_main(macho_header const*, unsigned long,
int, char const**, char const**, char const**)+0xb06
dyld`dyldbootstrap::start(macho_header const*, int,
char const**, long)+0x31f
dyld`_dyld_start+0x2a
firefox-bin`0x100000000
Once I see a different stack trace, e.g
libobjc.A.dylib`_mapStrHash+0xb
libobjc.A.dylib`NXMapGet+0x2f
libobjc.A.dylib`addNamedClass+0x26
libobjc.A.dylib`_read_images+0x247
libobjc.A.dylib`map_images_nolock+0x4f2
libobjc.A.dylib`map_images+0x72
dyld`dyld::notifyBatchPartial(dyld_image_states, bool,
char const* (*)(dyld_image_states, unsigned int, dyld_image_info
const*))+0x2fb
dyld`dyld::registerImageStateBatchChangeHandler
(dyld_image_states, char const* (*)(dyld_image_states, unsigned int,
dyld_image_info const*))+0x1ba
libSystem.B.dylib`dyld_register_image_state_change_handler+0x58
libobjc.A.dylib`_objc_init+0x3a
dyld`ImageLoaderMachO::doModInitFunctions
(ImageLoader::LinkContext const&)+0xe4
dyld`ImageLoader::recursiveInitialization
(ImageLoader::LinkContext const&, unsigned int)+0xec
dyld`ImageLoader::recursiveInitialization
(ImageLoader::LinkContext const&, unsigned int)+0x9d
dyld`ImageLoader::recursiveInitialization
(ImageLoader::LinkContext const&, unsigned int)+0x9d
dyld`ImageLoader::recursiveInitialization
(ImageLoader::LinkContext const&, unsigned int)+0x9d
dyld`ImageLoader::recursiveInitialization
(ImageLoader::LinkContext const&, unsigned int)+0x9d
dyld`ImageLoader::recursiveInitialization
(ImageLoader::LinkContext const&, unsigned int)+0x9d
dyld`ImageLoader::recursiveInitialization
(ImageLoader::LinkContext const&, unsigned int)+0x9d
dyld`ImageLoader::recursiveInitialization
(ImageLoader::LinkContext const&, unsigned int)+0x9d
dyld`ImageLoader::runInitializers
(ImageLoader::LinkContext const&)+0x3a
I know that initialization code in the libraries is being run.
I would expect dyld to always be doing the same thing with the same
library but either this is not the case or the kernel is reacting
completely different each time.
Here's iteration #1 (73 pages)
__LINKEDIT, __symtab = 2 pages, 5016 pages in
__LINKEDIT, __symtab = 2 pages, 5018 pages in
__DATA, __const = 4 pages, 4850 pages in
__DATA, __const = 4 pages, 4854 pages in
__DATA, __const = 4 pages, 4858 pages in
__DATA, __const = 4 pages, 4862 pages in
__DATA, __const = 4 pages, 4866 pages in
__DATA, __const = 6 pages, 4956 pages in
__DATA, __const = 6 pages, 4962 pages in
__DATA, __const = 6 pages, 4968 pages in
__DATA, __const = 6 pages, 4974 pages in
__DATA, __const = 6 pages, 4980 pages in
__DATA, __objc_classrefs = 6 pages, 4986 pages in
__DATA, __data = 6 pages, 4992 pages in
__DATA, __data = 7 pages, 4998 pages in
iteration #2 (84 pages)
__LINKEDIT, __symtab = 2 pages, 5018 pages in
__DATA, __const = 6 pages, 4962 pages in
__DATA, __const = 6 pages, 4968 pages in
__DATA, __const = 6 pages, 4974 pages in
__DATA, __const = 6 pages, 4980 pages in
__DATA, __objc_classrefs = 6 pages, 4986 pages in
__DATA, __data = 6 pages, 4992 pages in
__DATA, __data = 7 pages, 4998 pages in
__DATA, __data = 7 pages, 5005 pages in
__LINKEDIT, __symtab = 1 pages, 5024 pages in
__LINKEDIT, __symtab = 2 pages, 5025 pages in
__LINKEDIT, __symtab = 4 pages, 5027 pages in
__LINKEDIT, __symtab = 25 pages, 5031 pages in
and iteration #3 (54 pages)
__LINKEDIT, __symtab = 2 pages, 5016 pages in
__LINKEDIT, __symtab = 2 pages, 5018 pages in
__DATA, __const = 4 pages, 4850 pages in
__DATA, __const = 4 pages, 4854 pages in
__DATA, __const = 4 pages, 4858 pages in
__DATA, __const = 4 pages, 4862 pages in
__DATA, __const = 4 pages, 4866 pages in
__DATA, __const = 4 pages, 4870 pages in
__DATA, __const = 4 pages, 4874 pages in
__DATA, __const = 4 pages, 4878 pages in
__DATA, __const = 4 pages, 4882 pages in
__DATA, __const = 4 pages, 4886 pages in
__DATA, __const = 5 pages, 4916 pages in
__DATA, __const = 5 pages, 4951 pages in
---
firefox for android!
http://wagerlabs.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden