XPC.mfasl
Georg Maaß
the file XPC.mfasl is part of the user profile. Who is responsible for
invalidating this file i.e. after updating a *.jsm file? Changes to the
JavaScript module in a *.jsm file are not populated to the application
until the file XPC.mfasl has been deleted. Is there an API to tell
XulRunner to invalidate this file for all users on their next
application start? Deleting it via nsILocalFile might work for the
current user, but should fail for the file in other users profile for
security reasons. So I want to know whether there is an API to
invalidate the file globally to invoke Xulrunner to recreate it for each
user on his next application start.
MDC pages related to JavaScript modules do not mention such an API, or I
have tomatoes on my eyes. Probably there is a scriptable API, but I did
not yet detect it.
Best wishes, Georg
Neil
> the file XPC.mfasl is part of the user profile. Who is responsible for
> invalidating this file i.e. after updating a *.jsm file?
Which version of XulRunner? In 1.9.1 or earlier, my understanding is
that it invalidates automatically, but in 1.9.2 or later I think you
need to update your BuildID in application.ini which then causes all
your components to be rescanned.
--
Warning: May contain traces of nuts.
Benjamin Smedberg
> the file XPC.mfasl is part of the user profile. Who is responsible for
> invalidating this file i.e. after updating a *.jsm file? Changes to the
> JavaScript module in a *.jsm file are not populated to the application
> until the file XPC.mfasl has been deleted. Is there an API to tell
> XulRunner to invalidate this file for all users on their next
> application start? Deleting it via nsILocalFile might work for the
> current user, but should fail for the file in other users profile for
> security reasons. So I want to know whether there is an API to
> invalidate the file globally to invoke Xulrunner to recreate it for each
> user on his next application start.
When applications update their files they should ensure that their buildID
changes: all the caches (fastload, components, XPT) are invalidated when
either the platform version or the application buildid changes.
--BDS
Blair McBride
when doing incremental builds. It'd be great to somehow disable this for
development profiles.
- Blair
Benjamin Smedberg
> That's not too helpful when developing through - I was bitten by this
> when doing incremental builds. It'd be great to somehow disable this for
> development profiles.
debug builds should still have timestamp checking enabled for exactly this
reason. If you're using release builds like this, just remove XPC.mfasl from
the profile before launching.
--BDS
Georg Maaß
> When applications update their files they should ensure that their buildID
> changes: all the caches (fastload, components, XPT) are invalidated when
> either the platform version or the application buildid changes.
This is good to know. What stuff goes into XPC.mfasl and therefore needs
updating the build ID? Which stuff is affected by fastload?
Boris Zbarsky
> This is good to know. What stuff goes into XPC.mfasl and therefore needs
> updating the build ID?
Subscript loader and component loader, iirc.
> Which stuff is affected by fastload?
At the moment, XUL files. At some point XBL and stylesheets might be too.
-Boris
Benjamin Smedberg
> This is good to know. What stuff goes into XPC.mfasl and therefore needs
> updating the build ID? Which stuff is affected by fastload?
There are in fact two different files, XPC.mfasl and XUL.mfasl. XPC.mfasl is
the fastload cache for xpconnect stuff, which right now is JS components and
JS modules (Cu.import). XUL.mfasl is the fastload cache for chrome XUL
documents.
--BDS
Gijs Kruitbosch
This is possibly a stupid question, but, what about add-ons that update their
components/jsms?
~ Gijs
Neil
>XUL.mfasl is the fastload cache for chrome XUL documents.
>
>
And chrome scripts too, no?
The way that (debug) builds log every chrome resource just in case it's
used by XUL.mfasl sucks but I can't work out how to move the code to
somewhere more reasonable, such as when the document or script actually
gets written to fastload.
Georg Maaß
Is the content of XUL.mfasl controlled by the preferences
nglayout.debug.disable_xul_cache and nglayout.debug.disable_xul_fastload?
What exactly is fastload?
Why is it necessary to set both preferences to true in XulRunner
applications?
Best wishes, Georg
Benjamin Smedberg
> Is the content of XUL.mfasl controlled by the preferences
> nglayout.debug.disable_xul_cache and nglayout.debug.disable_xul_fastload?
I don't know what the difference is between these prefs.
> What exactly is fastload?
Parsing JavaScript and XML is slow. In order to improve the startup speed of
the app, on first startup we parse the JS and XML and save the parsed
version in a smaller and more efficient bytecode format (XDR for JS, I don't
know what for XUL/XBL) which subsequent startups use.
--BDS
Mike Beltzner
> Parsing JavaScript and XML is slow. In order to improve the startup speed of
> the app, on first startup we parse the JS and XML and save the parsed
> version in a smaller and more efficient bytecode format (XDR for JS, I don't
> know what for XUL/XBL) which subsequent startups use.
I bet this has been asked, but can we do this at build time, and then only do it again if we notice that the JS and XML has changed?
cheers,
mike
Benjamin Smedberg
Not without significant work. We'd have to do it on the build machines,
which involves building host versions of whatever tools are needed to do
this processing, which would be at least the JS engine. Depending on how we
wanted the fastload format to work, we could probably do XML fastload using
scripts (python), but that would involve additional maintenance to keep the
in-tree binary fastload reader and the scripted (python) fastload writer in
synch.
--BDS
Mike Shaver
Don't we already produce fastload files in the cases where we use PGO,
because we start the browser? Simply starting the browser and
shutting it down on the other systems as well would give us the bits
we need to package, I do believe.
Mike
Benjamin Smedberg
> Don't we already produce fastload files in the cases where we use PGO,
> because we start the browser? Simply starting the browser and
> shutting it down on the other systems as well would give us the bits
> we need to package, I do believe.
I am not sure whether our fastload files are arch-independent or not: we
tried to make them so at some point, and I believe we recently decided to go
the other way and not do endian normalization on fastload data.
I don't believe that we currently have the capability of running our build
on our build machines for all of our mobile targets (wince especially),
which is where this would make the most difference.
--BDS
Boris Zbarsky
>> nglayout.debug.disable_xul_cache and nglayout.debug.disable_xul_fastload?
>
> I don't know what the difference is between these prefs.
If nothing else, the XUL cache contains objects (like stylesheets) that
are not currently fastloaded.
-Boris
Boris Zbarsky
> Not without significant work. We'd have to do it on the build machines,
> which involves building host versions of whatever tools are needed to do
> this processing, which would be at least the JS engine. Depending on how we
> wanted the fastload format to work, we could probably do XML fastload using
> scripts (python)
Not without changing the fastload format or putting a lot of work into
said scripts. Right now the fastload file stores all the prototype
document inforamtion, including the serialized principals, uris,
nodeinfo table, etc, etc.
-Boris
Mike Shaver
<benj...@smedbergs.us> wrote:
> I am not sure whether our fastload files are arch-independent or not: we
> tried to make them so at some point, and I believe we recently decided to go
> the other way and not do endian normalization on fastload data.
Sure, we'd generate them for the platforms in question.
> I don't believe that we currently have the capability of running our build
> on our build machines for all of our mobile targets (wince especially),
> which is where this would make the most difference.
We can have that capability through the test agent pretty soon, I suspect.
Mike
Mike Beltzner
> Sure, we'd generate them for the platforms in question.
Filed https://bugzilla.mozilla.org/show_bug.cgi?id=530606 to track the build piece; I don't know if we already do the check and only regenerate when things have changed piece. If not, we'd need another bug for that.
cheers,
mike
Blair McBride
Boris Zbarsky
> Its probably going to change anyway:
> https://bugzilla.mozilla.org/show_bug.cgi?id=520309
Is that just changing the on-disk byte format, or changing the set of
internal data structures, not obviously available from a piece of XML,
that we store? That latter is what makes it more difficult to use
off-the-shelf things to create fastload files.
-Boris
Blair McBride
sounds like now would probably be a good time to make some noise.
- Blair
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
Taras Glek
I'm not sure what is being asked above, but I think it's asking for the
motivation behind the newfangled startup cache component.
The goal there is to allow caching stuff within a single file.
* Currently to cache stuff via fastload one has to create a new
file(perf hit) per thing cached
* Currently, to cache stuff one has to write a lot of code, goal is to
have a single component where startup-related stuff can be handed off to
* To avoid interleaved file format complexity
* startup cache prototype is currently based on jar code as it is a
well-understood format, allows piecemeal checksumming and it is already
fairly optimized for the startup case.
* Eventually this will allow to do single-file cache invalidation.
Currently fasl is append-only so best thing to do when a file changes is
to delete the whole cache.
* That and fasl is in need of a massive deCOMtamination, which would
rewrite rewriting all existing fasl code to fix.
Cheers to benh for taking this on.
Taras
Boris Zbarsky
>> Is that just changing the on-disk byte format, or changing the set of
>> internal data structures, not obviously available from a piece of XML,
>> that we store? That latter is what makes it more difficult to use
>> off-the-shelf things to create fastload files.
>
> I'm not sure what is being asked above, but I think it's asking for the
> motivation behind the newfangled startup cache component.
No, it was just a question about the scope of the change in the context
of evaluating how and whether it impacts the proposal to pregenerate the
fastload files using a python script.
-Boris
Ben
It shouldn't significantly impact the proposal to generate the files
using a python script. We store startup-cache files on a per-
architecture basis, so if you got your file generated for the wrong
arch, the worst thing that happens is you write a new file.
The startupcache literally just provides clients with a way to
associate a byte array with a string key; clients can use that
functionality in any way they choose. It's simpler than fastload in
that sense. Current clients of fastload will just write their data to
a buffer first, then hand it to startupcache (there is a patch in the
bug that makes this happen).