Quantcast
Channel: mayhemer's blog
Viewing all 43 articles
Browse latest View live

New Firefox HTTP cache now enabled on Nightly builds

0
0

Yes, it’s on!  After a little bit more than a year of a development by me and Michal Novotný all bugs we could find in our labs, offices and homes were fixed.  The new cache back-end is now enabled on Firefox Nightly builds as of version 32 and should stay like that.

The old cache data are for now left on disk but we have handles to remove them automatically from users’ machines to not waste space since it’s now just a dead data.  This will happen after we confirm the new cache sticks on Nightlies.

The new HTTP cache back end has many improvements like request prioritization optimized for first-paint time, ahead of read data preloading to speed up large content load, delayed writes to not block first paint time, pool of most recently used response headers to allow 0ms decisions on reuse or re-validation of a cached payload, 0ms miss-time look-up via an index, smarter eviction policies using frecency algorithm, resilience to crashes and zero main thread hangs or jank.  Also it eats less memory, but this may be subject to change based on my manual measurements with my favorite microSD card which shows that keeping at least data of html, css and js files critical for rendering in memory may be wise.  More research to come.

Thanks to everyone helping with this effort.  Namely Joel Maher and Avi Halachmi for helping to chase down Talos regressions and JW Wang for helping to find cause of one particular hard to analyze test failure spike.  And also all early adopters who helped to find and fix bugs.  Thanks!

 

New preferences to play with:

 

browser.cache.disk.metadata_memory_limit
Number of kBs we reserve for keeping recently loaded cache entries metadata (i.e. response headers etc.) for quick access and re-validation or reuse decisions.  By default this is at 250kB.
browser.cache.disk.preload_chunk_count
Number of data chunks we always preload ahead of read to speed up load of larger content like images.  Currently size of one chunk is 256kB, and by default we preload 4 chunks – i.e. 1MB of data in advance.

 

Load times compare:

Since these tests are pretty time consuming and usually not very precise, I was only testing with page 2 of my blog that links some 460 images.  Media storage devices available were: internal SSD, an SDHC card and a very slow microSD via a USB reader on a Windows 7 box.

 

[ complete page load time / first paint time ]

SSD
Cache version First visit Cold go to 1) Warm go to 2) Reload
cache v1 7.4s / 450ms 880ms / 440ms 510ms / 355ms 5s / 430ms
cache v2 6.4s / 445ms 610ms / 470ms 470ms / 360ms 5s / 440ms

 

Class 10 SDHC
Cache version First visit Cold go to 1) Warm go to 2) Reload
cache v1 7.4s / 635ms 760ms / 480ms 545ms / 365ms 5s / 430ms
cache v2 6.4s / 485ms 1.3s / 450ms 530ms / 400ms* 5.1s / 460ms*

 

Edit: I found one more place to optimize – preload of data sooner in case an entry has already been used during the browser session (bug 1013587).  We are winning around 100ms for both first paint and load times!  Also stddev of first-paint time is smaller (36) than before (80).  I have also measured more precisely the load time for non-patched cache v2 code.  It’s actually better.

Slow microSD
Cache version First visit Cold go to 1) Warm go to 2) Reload
cache v1 13s / 1.4s 1.1s / 540ms 560ms / 440ms 5.1s / 430ms
cache v2 6.4s / 450ms 1.7s / 450ms 710ms / 540ms* 5.4s / 470ms*
cache v2 (with bug 1013587) - - 615ms / 455ms* -

* We are not keeping any data in memory (bug 975367 and 986179) what seems to be too restrictive.  Some data memory caching will be needed.

 

“Jankiness” compare:

The way I have measured browser UI jank (those hangs when everything is frozen) was very simple: summing every stuck of the browser UI, taking more then 100ms, between pressing enter and end of the page load.

 

[ time of all UI thread events running for more then 100ms each during the page load ]

SSD
Cache version First visit Cold go to 1) Warm go to 2) Reload
cache v1 0ms 600ms 0ms 0ms
cache v2 0ms 0ms 0ms 0ms

 

Class 10 SDHC
Cache version First visit Cold go to 1) Warm go to 2) Reload
cache v1 600ms 600ms 0ms 0ms
cache v2 0ms 0ms 0ms 0ms

 

Slow microSD
Cache version First visit Cold go to 1) Warm go to 2) Reload
cache v1 2500ms 740ms 0ms 0ms
cache v2 0ms 0ms 0ms 0ms

 

All load time values are medians, jank values averages, from at least 3 runs without extremes in attempt to lower the noise.

 

1) Open a new tab and navigate to a page right after the Firefox start.

2) Open a new tab and navigate to a page that has already been visited during the browser session.

 


Headless Fedora 20 and VNC with autologin

0
0

“Oh no! Something has gone wrong” message is all what you get when you VNC to Gnome 3 in Fedora 20 on a box without any physical monitor attached to any of the video outputs with enabled autologin and screen sharing (vino).  There is an error in /var/log/messages ‘TypeError: this.primaryMonitor is undefined’ at /usr/share/gnome-shell/js/ui/layout.js:410.  I haven’t found a Fedora bug open for this.

You cannot also simply configure e.g. tiger-vnc because of other two bugs, one closed and one open preventing login screen from entering the password – as somebody would be pressing the entry key on and on.

I was not able to find a straight and simple fix unless I’ve hit this solution for Ubuntu, and ported it to Fedora 20:

  • #yum install xorg-x11-drv-dummy
  • put this content to /etc/X11/xorg.conf (you will probably need to create the file):

Section “Monitor”
Identifier “Monitor0″
HorizSync 28.0-80.0
VertRefresh 48.0-75.0
Modeline “1280×800″  83.46  1280 1344 1480 1680  800 801 804 828 -HSync +Vsync
EndSection

Section “Device”
Identifier “Card0″
Option “NoDDC” “true”
Option “IgnoreEDID” “true”
Driver “dummy”
EndSection

Section “Screen”
DefaultDepth 24
Identifier “Screen0″
Device “Card0″
Monitor “Monitor0″
SubSection “Display”
Depth 24
Modes “1280×800″
EndSubSection
EndSection

You can then VNC to port :0 and you will be logged in directly without a need to enter the user password.  I suggest SSH tunneling.

 

NGC 7000, NGC 6974, IC 1318 a okolí + IR

0
0

NGC 7000, NGC 6974, IC 1318

NGC 7000, NGC 6974, IC 1318 + Infrared

 

Dvě téměř zapomenuté fotky z lokace jižně od Prahy, focené loni v létě v noci z 16. na 17. června. Velmi krátká noc, slunce definitivně zapadlo snad až před jedenáctou a po druhé už zase začalo svítat. Zato divokých psů a prasat v okolní vysoké trávě bylo požehnaně :)

 

Horní fotografie je jen viditelné světlo, dolní má modrý overlay v IR pásmu nad 742nm. Kvalita je sice mizerná, základ je vždy jen jedna fotografie, ale mě se to líbí.

 

Canon 30D, MC mod
Canon EF 35mm/F2
HEQ5, ustavena tentokrát driftovou metodou
Astronomik CLS-CCD: 1x600s @ F4.0, ISO 1000
Astronomik ProPlanet IR 742: 1x300s @ F4.0, ISO 1000
0x Flat/Dark/Bias
Zpracování v CR a PS

HTTP cache v1 API disabled

0
0

Recently we landed the new HTTP cache for Firefox (“cache2″) on mozilla-central.  It has been in nightly builds for a while now and seems very likely to stick on the tree and ship in Firefox 32.

Given the positive data we have so far, we’re taking another step today to making the new cache official: we have disabled the old APIs for accessing the HTTP cache, so addons will now need to use the cache2 APIs. One important benefit of this is that the cache2 APIs are more efficient and never block on the main thread.  The other benefit is that the old cache APIs were no longer pointing at actual data any more (it’s in cache2) :)

This means that the following interfaces are now no longer supported:

  •   nsICache
  •   nsICacheService
  •   nsICacheSession
  •   nsICacheEntryDescriptor
  •   nsICacheListener
  •   nsICacheVisitor

(Note: for now nsICacheService can still be obtained: however, calling any of its methods will throw NS_ERROR_NOT_IMPLEMENTED.)

Access to previously stored cache sessions is no longer possible, and the update also causes a one-time deletion of old cache data from users’ disks.

Going forward addons must instead use the cache2 equivalents:

  •   nsICacheStorageService
  •   nsICacheStorage
  •   nsICacheEntry
  •   nsICacheStorageVisitor
  •   nsICacheEntryDoomCallback
  •   nsICacheEntryOpenCallback

Below are some examples of how to migrate code from the old to the new cache API.  See the new HTTP cache v2 documentation for more details.

The new cache2 implementation gets rid of some of terrible features of the old cache (frequent total data loss, main thread jank during I/O), and significantly improves page load performance.  We apologize for the developer inconvenience of needing to upgrade to a new API, but we hope the performance benefits outweight it in the long run.

Example of the cache v1 code (now obsolete) for opening a cache entry:

var cacheService = Components.classes["@mozilla.org/network/cache-service;1"]
                   .getService(Components.interfaces.nsICacheService);

var session = cacheService.createSession(
  "HTTP",
  Components.interfaces.nsICache.STORE_ANYWHERE,
  Components.interfaces.nsICache.STREAM_BASED
);

session.asyncOpenCacheEntry(
  "http://foo.com/bar.html",
  Components.interfaces.nsICache.ACCESS_READ_WRITE,
  {
    onCacheEntryAvailable: function (entry, access, status) {
      // And here is the cache v1 entry
    }
  }
);

Example of the cache v2 code doing the same thing:

let {LoadContextInfo} = Components.utils.import(
  "resource://gre/modules/LoadContextInfo.jsm", {}
);

var cacheService = Components.classes["@mozilla.org/netwerk/cache-storage-service;1"]
                   .getService(Components.interfaces.nsICacheStorageService);

var storage = cacheService.diskCacheStorage(
  LoadContextInfo.default,
  false
);

storage.asyncOpenURI(
  makeURI("http://foo.com/bar.html"),
  "",
  Components.interfaces.nsICacheStorage.OPEN_NORMALLY,
  {
    onCacheEntryCheck: function (entry, appcache) {
      return Ci.nsICacheEntryOpenCallback.ENTRY_WANTED;
    },
    onCacheEntryAvailable: function (entry, isnew, appcache, status) {
      // And here is the cache v2 entry
    }
  }
);

 

There is a lot of similarities, instead of a cache session we now have a cache storage having a similar meaning – to represent a distinctive space in the whole cache storage – it’s just less generic as it was before so that it cannot be misused now.  There is now a mandatory argument when getting a storage – nsILoadContextInfo object that distinguishes whether the cache entry belongs to a Private Browsing context, to an Anonymous load or has an App ID.

(Credits to Jason Duell for help with this blog post)

The post HTTP cache v1 API disabled appeared first on mayhemer's blog.

Just a photo…

Částečné zatmění slunce 2015

0
0

Je to hodně z ruky, selhala dálková programovatelná spoušť a na focení po přesných intervalech jsem byl prostě líný :) Aligning není úplně přesný, ale mě se to líbí i tak.

Stativ, Canon EOS 60D, Canon EF 200/2.8 L II, ND8 + Baader Astrosolar.  Každý snímek animace cca 6 – 10 RAW obrazů @ ISO 100, 1/125s, F/4, bez flatfield.  Registax 6.

partial-solar-eclipse-2015-animation

The post Částečné zatmění slunce 2015 appeared first on mayhemer's blog.

New Gecko performance tool: Backtrack

0
0

Backtrack aims to show a complete code path flow from any point back to its source, crossing asynchronous callbacks, threads, processes, network requests, timers and any kind of implementation specific queuing plus capturing any I/O or mutex blockade.  The ‘critical flow execution path’ is put to a context of all the remaining concurrent execution flows.  It’s then easy to examine how the critical flow is blocked and delayed by concurrent tasks.

The work is tracked in this bug, where you also find patches and build instructions.  There is also an add-on that, in Backtrack enabled builds, allows you to view actual captured data.

Click the screenshot bellow to view an interactive previewIt’s capture of load of my blog main page till the first-paint notification (no e10s and no network predictor to demonstrate the capture capabilities.)

backtrack-preview-1

Backtrack combines*) Gecko Profiler and Task Tracer.

Gecko Profiler (PSP) provides instrumentation (already spread around the code base) to capture static call stacks.  I’ve enhanced the PSP instrumentation to also capture objects (i.e. 'this' pointer value) and added a simple base class to easily monitor object life time (classes must be instrumented.)

Task Tracer (TT) on the other hand provides a generic way to track back on runnables – but not on e.g. network poll results, network requests or implementation specific queues.  It was easy to add a hook into the TT code that connects the captured object inter-calls with information about runnables dispatch source and target.

The Backtrack experimental patch:

  • Captures object lifetime (simply add ProfilerTracked<class Derived> as a base class to track the object lifetime and class name automatically)
  • Annotates objects with resource names (e.g URI, host name) they work with at run-time
  • Connects stack and object information using the existing PROFILER_LABEL_FUNC instrumentation recording this pointer value automatically ; this way it collects calls between objects
  • Measures I/O and mutex wait time ; an object holding a lock can be easily found
  • Sticks receipt of a particular network response exactly to its actual request transmission (here I mainly mean HTTP but also applies to connect() and DNS resolution)
  • Joins network polling “ins” and “outs”
  • Binds code-specific queuing and dequeuing, like our DNS resolver, HTTP request queues.  Those are not just ‘dispatch and forget’ like nsIEventTarget and nsIRunnable but rather have priorities, complex dequeue conditions and may not end up dispatched to just a single thread.  These queues are very important from the resource scheduling point of view.

Followups:

  • IPC support, i.e. cross also processes
  • Let the analyzes also mark anything ‘related’ for achieving a selected path end (e.g. my favorite first-paint time and all CSS loads involved)
  • Probably persist the captured raw logs and allow the analyzes be done offline

Disadvantages: just one – significant memory consumption.

*) The implementation is so far not deeply bound to SPS and TT memory data structures.  I do the capture my own – actually a third data collection, side by SPS and TT.  I’m still proving the concept this way but if found useful and bearable to land in this form as a temporary way of collecting the data, we can optimize and cleanup as a followup work.

The post New Gecko performance tool: Backtrack appeared first on mayhemer's blog.

Unseen astronomical phenomenon discovered


TCPSocket.js/TCPServerSocket.js IPC mess captured

0
0

TCPSocket implemented in Javascript is a DOM technology providing web pages a direct access to TCP network sockets.  We support both outgoing connections and listening to incoming connections via a server socket.

I’m constantly requested to review changes under this code in /dom/network where TCPSocket et al resides.  And I’m always lost in the mess of all classes and objects involved in the IPC bridging.

As a side result of the last review request I’ve dived into the jungle and crated a “UML” flow chart that helps me understand – and not forget again – the complicated flow of IPC’ing in both TCPSocket and TCPServerSocket.

Here they are.

TCPSocket IPCTCPServerSocket IPC

Not perfect, I’m no UML expert, but I think one can understand and make a picture that may be helpful ;)

The post TCPSocket.js/TCPServerSocket.js IPC mess captured appeared first on mayhemer's blog.

String parsing made simple with mozilla::Tokenizer

0
0

 

PL_strstr

 

I can see FindChar, Substring, ToInteger and even atoi, strchr, strstr and sscanf craziness all over the Mozilla code base. There are though much better and, more importantly, safer ways to parse even a very simple input.

I wrote a parser class with API derived from lexical analyzers that helps with simple inputs parsing in a very easy way. Just include mozilla/Tokenizer.h and use class mozilla::Tokenizer. It implements a subset of features of a lexical analyzer.  Also nicely hides boundary checks of the input buffer from the consumer.

To describe the principal briefly: Tokenizer recognizes tokens like whole words, integers, white spaces and special characters.  Consumer never works directly with the string or its characters but only with pre-parsed parts (identified tokens) returned by this class.

 

There are two main methods of Tokenizer:

  • bool Next(Token& result);

If there is anything to read from the input at the current internal read position, including the EOF, returns true and result is filled with a token type and an appropriate value easily accessible via a simple variant-like API.  The internal read cursor is shifted to the start of the next token in the input before this method returns.

  • bool Check(const Token& tokenToTest);

If a token at the current internal read position is equal (by the type and the value) to what has been passed in the tokenToTest argument, true is returned and the internal read cursor is shifted to the next token.  Otherwise (token is different than expected) false is returned and the read cursor is left unaffected.

Few usage examples:

Construction

  #include "mozilla/Tokenizer.h"

  mozilla::Tokenizer p(NS_LITERAL_CSTRING("Sample string 2015."));

Reading a single token, examining it

  mozilla::Tokenizer::Token t;
  bool read = p.Next(t);
  // read == true, we have read something and t has been filled
  // Following our example string...
  if (t.Type() == mozilla::Tokenizer::TOKEN_WORD) {
    t.AsString(); // returns "Sample"
  }

Checking on a token value and automatically skipping on a positive test

  if (!p.CheckChar('\x20')) {
    throw "I expect a space here!";
  }

  read = p.Next(t);
  // read == true
  t.Type() == mozilla::Tokenizer::TOKEN_WORD;
  t.AsString() == "string";

  if (!p.CheckWhite()) {
    throw "A white space is expected here!";
  }

Reading numbers

  read = p.Next(t);
  // read == true
  t.Type() == mozilla::Tokenizer::TOKEN_INTEGER;
  t.AsInteger() == 2015;

Reaching the end of the input

  read = p.Next(t);
  // read == true
  t.Type() == mozilla::Tokenizer::TOKEN_CHAR;
  t.AsChar() == '.';

  read = p.Next(t);
  // read == true
  t.Type() == mozilla::Tokenizer::TOKEN_EOF;

  read = p.Next(t);
  // read == false, we are behind the EOF
  // t is here undefined!

More features

To learn more enhanced features of the Tokenizer – there is not that many, don’t be scared ;) – look at the well documented Tokenizer.h file under xpcom/ds.

As a teaser you can go through this more enhanced example or check on a gtest for Tokenizer:

#include "mozilla/Tokenizer.h"

using namespace mozilla;

{
  // A simple list of key:value pairs delimited by commas
  nsCString input("message:parse me,result:100");

  // Initialize the parser with an input string
  Tokenizer p(input);
  // A helper var keeping type and value of the token just read
  Tokenizer::Token t;

  // Loop over all tokens in the input
  while (p.Next(t)) {
    if (t.Type() == Tokenizer::TOKEN_WORD) {
      // A 'key' name found
      if (!p.CheckChar(':')) {
        // Must be followed by a colon
        return; // unexpected character
      }

      // Note that here the input read position is just after the colon
      // Now switch by the key string
      if (t.AsString() == "message") {
        // Start grabbing the value
        p.Record();
        // Loop until EOF or comma
        while (p.Next(t) && !t.Equals(Tokenizer::Token::Char(',')))
          ;
        // Claim the result
        nsAutoCString value;
        p.Claim(value);
        MOZ_ASSERT(value == "parse me");

        // We must revert the comma so that the code bellow recognizes the flow correctly
        p.Rollback();
      } else if (t.AsString() == "result") {
        if (!p.Next(t) || t.Type() != Tokenizer::TOKEN_INTEGER) {
          return; // expected a value and that value must be a number
        }

        // Get the value, here you know it's a valid number
        uint32_t number = t.AsInteger();
        MOZ_ASSERT(number == 100);
      } else {
        // Here t.AsString() is any key but 'message' or 'result', ready to be handled
      }

      // On comma we loop again
      if (p.CheckChar(',')) {
        // Note that now the read position is after the comma
        continue;
      }
      // No comma?  Then only EOF is allowed
      if (p.CheckEOF()) {
        // Cleanly parsed the string
        break;
      }
    }

    return; // The input is not properly formatted
  }
}

 

Currently works only with ASCII inputs but can be easily enhanced to also support any UTF-8/16 coding or even specific code pages if needed.

The post String parsing made simple with mozilla::Tokenizer appeared first on mayhemer's blog.

INACCESSIBLE_BOOT_DEVICE on Windows 10 boot after update of the Intel Rapid Storage Techonology driver

0
0

Have a BSOD after you’ve installed the latest version of Intel RST, 14.6.0.1029, from Intel’s download center? During the boot, staring at the Windows logo and the spinning wheel, after a minute or two getting just INACCESSIBLE_BOOT_DEVICE error and “we must reboot” message?  Restarts, nothing helps? Yeah, I’ve been there.

Two and a half hour of googling, reverting registry settings, looping in the auto recovery mode, until I found out myself a simple solution for reverting the Intel RST driver update:

Note: can be applied only when you have updated the driver from a previously working version, since it counts with a previous driver file stored on your disk.

  • Check your BIOS and RAID setting are as expected, since I once encountered iRST update that screwed that up – actually turned off RAID!
  • During boot hold F8
  • Choose Troubleshoot
  • Choose Advanced options
  • Choose Command Prompt, a command prompt window, as you know it, should open
  • My system drive was mounted as E:, if yours is mounted elsewhere, replace E: in below commands with that latter
  • At the prompt type:
    • cd /d E:\Windows\system32\drivers
    • ren iaStorA.sys iaStorA.sys-bad-version
    • cd ..
    • dir /s iaStorA.sys
  • That will list something like this:
     Volume in drive C has no label.
    Volume Serial Number is XXXX-XXXX
    
     Directory of E:\Windows\System32\drivers
    
    07/29/2015  19:44         1,462,720 iaStorA.sys
                   1 File(s)      1,462,720 bytes
    
     Directory of E:\Windows\System32\DriverStore\FileRepository\iastorac.inf_amd64_26544f4e51074f52
    
    05/28/2014  10:10           672,104 iaStorA.sys
                   1 File(s)        672,104 bytes
    
     Directory of E:\Windows\System32\DriverStore\FileRepository\iastorac.inf_amd64_61378e65f4f142a0
    
    07/29/2015  19:44         1,462,720 iaStorA.sys
                   1 File(s)      1,462,720 bytes
    
         Total Files Listed:
                   3 File(s)      2,806,928 bytes
     
     
    
  • For me the previous working driver file is apparently at DriverStore\FileRepository\iastorac.inf_amd64_26544f4e51074f52, yours can be elsewhere, so update the source directory in the copy command below according that
  • Continue typing following commands, you should still be at the E:\Windows\System32 directory:
    • copy DriverStore\FileRepository\iastorac.inf_amd64_26544f4e51074f52\iaStorA.sys drivers\iaStorA.sys
  • You should see a “1 file(s) copied” message
    • exit
  • Now normally reboot
  • Good luck!

After that Intel RST service still starts up, shows the status etc, disks are fine, everything seems to work, even after another (deliberate) reboot. Only weird thing was that System Restore for the C: drive was turned off. Not sure if it was caused by the RST update, by the boot problems, by some of my other manual changes (not listed here) or what.. Re-enabling it works fortunately well, so not an issue.

A good thing to do is yet to rollback the driver from the Device Manager (Storage Controllers/Intel(R) *** SATA RAID Controller/Properties/Driver/Roll Back Driver) to put the registry records back to the correct state.

Conclusion: Don’t update the Intel Rapid Storage Technology driver!

The post INACCESSIBLE_BOOT_DEVICE on Windows 10 boot after update of the Intel Rapid Storage Techonology driver appeared first on mayhemer's blog.

Filter out errors out of mozilla build on command line

0
0

Mozilla build errors filtered once again under the build log

I wrote a small filter script that lists all build errors once again at the bottom of the whole build log, so that you don’t have to look for them like for a needle in a haystack. Something I wanted mach to do natively.  But I was always told something like “filter yourself”.  So here it is :)

  • Download this small script *)
  • Copy it to your source directory or somewhere your $PATH points to
  • run mach as: ./mach build | err

When there are errors during build, those will be listed under the build log and conveniently highlighted.

*) It’s tuned for and mainly targeting mingw, but might well work on linux/osx too.

The post Filter out errors out of mozilla build on command line appeared first on mayhemer's blog.

Backtrack meets Gecko Profiler

0
0

Backtrack is about to be a new performance tool, focused on revealing and solving scheduling and delay problems.  Those are big offenders of performance, very hard to track, and hidden from conventional profilers.

To find out how long and what all has to happen to reach a certain point – an objective, just add a simple instrumentation marker.  When hit during run, it’s added to a list you can then pick from and start tracing to its origin.  Backtrack follows from the selected objective back to the originating user input event that has started the whole processing chain.

The walk-back crosses runnables and their wait time in thread event queues, but also network requests and responses, any code specific queues such as DOM mutations, scheduled reflows or background JS parsing 1), monitor and condvar notifications, mutex acquirements 2), and disk I/O operations.

Visually the result is a single timeline – we can call it a critical path – revealing wait, network and CPU times as distinct intervals involved in reaching solely the selected objective.  Spotting mainly dispatch wait delays is then very easy.  The most important and new is that Backtrack tells you what other operations or events block (makes the critical path wait) and where from have been scheduled.  And more importantly, it recognizes which of them are (or are not) related to reaching the selected objective.  Those not related are then clear candidates for rescheduling.

To distinguish related and unrelated operations Backtrack captures all sub-tasks that are involved in reaching the selected objective.  Good example is the page first paint time – actually unsuppress of painting.  First paint is blocked by loading more than one resource, the HTML and head referenced CSS and JS.  These loads and their processing – the sub-tasks – happen in parallel and only completion of all of them unsuppresses the painting (said in a very simplified way, of course.)  Each such sub-task’s completion is marked with an added instrumentation.  That creates a list of sub-objectives that are then added to the whole picture.

Screen shot of how Backtrack is integrated to the Gecko Profiler Cleopatra web UI

Future improvements:

  • Backtrack could be used in our perfomance automation.  Except calculation of time between an objective and its input source event, it can also calculate CPU vs dispatch delays vs network response time.  It could also be able to filter out code paths clean of any outer jitter.
  • Indeed, networking has strong influence to load times.  Adding more detailed breakdown and analyzes how well we schedule and allocate network resources is one of the next steps.
  • Adding PCAPs or even let Backtrack capture network activity like Wireshark directly from inside Firefox and join it with the Gecko Profiler UI might help too.

The current state of Backtrack development is a work in active progress and is not yet available to users of Gecko Profiler.  There are patches for Gecko, but also for the Cleopatra UI and the Gecko Profiler Add-on.  The UI changes, where also the analyzes happens, are mostly prototype-like and need a clean up.  There are also problems with larger memory consumption and bigger chances to hit OOMs when processing the captured data with Backtrack captured markers.


1) code specific queues need to be manually instrumented
2) with ability to follow to the thread that was keeping the mutex for the time you were waiting to acquire it

 

The post Backtrack meets Gecko Profiler appeared first on mayhemer's blog.

Illusion of atomic reference counting

0
0

Most people believe that having an atomic reference counter makes them safe to use RefPtr on multiple threads without any more synchronization.  Opposite may be truth, though!

Imagine a simple code, using our commonly used helper classes, RefPtr<> and an object Type with ThreadSafeAutoRefCnt reference counter and standard AddRef and Release implementations.

Sounds safe, but there is a glitch most people may not realize.  See an example where one piece of code is doing this, no additional locks involved:

RefPtr<Type> local = mMemeber; // mMember is RefPtr<Type>, holding an object

And other piece of code then, on a different thread presumably:

mMember = new Type(); // mMember's value is rewritten with a new object

Usually, people believe this is perfectly safe.  But it’s far from it.

Just break this to actual atomic operations and put the two threads side by side:

Thread 1

local.value = mMemeber.value;
/* context switch */ 
.
.
.
.
.
.
local.value->AddRef();

Thread 2

.
.
Type* temporary = new Type();
temporary->AddRef();
Type* old = mMember.value; 
mMember.value = temporary; 
old->Release(); 
/* context switch */ 
.

Similar for clearing a member (or a global, when we are here) while some other thread may try to grab a reference to it:

RefPtr<Type> service = sService;
if (!service) {
  return; // service being null is our 'after shutdown' flag
}

And another thread doing, usually during shutdown:

sService = nullptr; // while sService was holding an object

And here what actually happens:

Thread 1

local.value = sService.value;
/* context switch */
.
.
.
.
local.value->AddRef();

Thread 2

.
.
Type* old = sService.value; 
sService.value = nullptr; 
old->Release(); 
/* context switch */
.

And where is the problem?  Clearly, if the Release() call on the second thread is the last one on the object, the AddRef() on the first thread will do its job on a dying or already dead object.  The only correct way is to have both in and out assignments protected by a mutex or, ensure that there cannot be anyone trying to grab a reference from a globally accessed RefPtr when it’s being finally released or just being re-assigned. The letter may not always be easy or even possible.

Anyway, if somebody has a suggestion how to solve this universally without using an additional lock, I would be really interested!

The post Illusion of atomic reference counting appeared first on mayhemer's blog.

Moz logging (former NSPR logging) file now has a size limit option

0
0

There are lot of cases of mainly networking issues rare enough to reproduce making users have their Firefox run for long hours to hit the problem.  Logging is great in bringing the information to us when finally reproduced, but after few hours the log file can be – well – huge.  Easily even gigabytes.

But now we have a size limit, all you need to do:

Adding rotate module to the list of modules will engage log file size limit:

MOZ_LOG=rotate:200,log modules...

The argument is the limit in megabytes.

This will produce up to 4 files with names appended a numbering extension, .0, .1, .2, .3.  The logging back end cycles the files it writes to while sum of these files’ sizes will never go over the specified limit.

The patch just landed on mozilla-central (version 51), bug 1244306.

Note 1: the file with the largest number is not guarantied to be the last file written.  We don’t move the files, we only cycle.  Using the rotate module automatically adds timestamps to the log, so it’s always easy to recognize which file keeps the most recent data.

Note 2: rotate doesn’t support append.  When you specify rotate, on every start all the files (including any previous non-rotated log file) are deleted to avoid any mixture of information.  The append module specified is then ignored.

The post Moz logging (former NSPR logging) file now has a size limit option appeared first on mayhemer's blog.


Just a photo…

Intel Rapid Storage Technology disappears on Windows 10 and more

0
0

This started with the INACCESSIBLE_BOOT_DEVICE doom I wrote about before.  But here I want to treat the story after that.

When I solved the above mentioned problem, I ended up with 14.6 version of the driver in the system.  Everything worked well.

Until few months ago, the Intel Rapid Storage Technology UI completely disappeared from my system.  Only an empty folder under Program Files left.  Like somebody would steal it… Despite that, it still was listed as an installed software in Control Panels.

Since the UI part is important, I decided to gain it back.

But before running any SetupRST installers I rather inspected and prepared the system.  And what I found to my surprise!  The Intel’s driver for the RAID storage was missing.  I was on the Microsoft’s one (EhStorClass.sys).  That was very interesting thing I didn’t expect.

The preparation part #1 – create a restore point!

And preparation part #2 – check that restore point is accessible from the Recovery mode.  And here it starts :)  Pressing F8 during Windows 10 boot no longer works.  Hence, on this very same machine, I created a restore USB drive.  Booted from it.  Trying to access the list of restore points – “first select a system.”  What?  Aha!  The system drive didn’t mount in the Recovery mode!  This means that there is something wrong with this affected system.  But I don’t have intentions finding out what.

Fortunately, having a laptop with Windows 10 helped here.  That laptop didn’t have iRST installed, ever.  Creating a restore drive on a different machine and booting back on the ill machine makes the list of restore points visible.  Now I can proceed.

I decided to install only the iRST UI.  As reported in the original blog post comments, 14.0.0.1143 version is considered safe to install regarding the INACCESSIBLE_BOOT_DEVICE error.  Hence, I downloaded the setup from Intel.

Running it started to complain that iRST was already installed.  I exited the setup and uninstalled the iRST using Control Panels.  Then restarted with fingers crossed.  And the system… booted!  And the Microsoft’s driver didn’t move a bit.

Next step.  Running the setup again, now it complains that there is a newer Intel Rapid Storage driver, version 14.6.x.x.  If it’s there and it used to work, then why not to keep it?

Hence, this time I run SetupRST with -Nodrv command line argument to don’t install the driver.  According to my understanding, it should only install the missing UI.  Setup installs, asks for restart.  I do it, and the system… still boots!

The Intel Rapid Storage Technology UI is there after boot, as used to be!  There is also still the Microsoft driver.  The iRST UI works with it as expected and is also able to check the volume for errors.  Nice.

But somehow I’d rather have iRST UI, the service and the driver from one company.  One never knows if when changing the volume parameters like changing the drives, enlarging etc would break in any bad combination.

Hence, I run SetupRST again, no arguments.  It asks for either uninstall or repair.  I choose repair.  It does its job, asks for reboot.  I do it, and the system… yes, still boots :)

The final result: I have both the iRST driver and the iRST UI back.
User interface version:  14.0.0.1143
Driver version:  14.6.0.1029

This seems to work well.  I can again see status of all volumes and disks, and hopefully also manage volumes safely as before.

I hope this may help anyone experiencing iRST UI being mysteriously ripped off the Windows 10 system.

The post Intel Rapid Storage Technology disappears on Windows 10 and more appeared first on mayhemer's blog.

Automatically attaching child and test-spawned Firefox processes in Visual Studio IDE

0
0

Did you ever dream of debugging Firefox in Visual Studio with all its child processes attached automatically?  And also when being started externally from a test suit like mochitest or browsertest?  Tired of finding the right pid and time to attach manually?  Here is the solution for you!

Combination of the following two extensions to Visual Studio Community 2015 will do the trick:

  1. Spawned Process Catcher X – attaches automatically to all child processes the debugee (and its children) spawns
  2. Entrian Attach – attaches the IDE automatically to an instance of a process spawned FROM ANYWHERE, e.g. when running tests via mach where Firefox is started by a python script – yes, magic happens ;)

Spawned Process Catcher X works automatically after installation without a need for any configuration.

Entrian Attach is easy to configure: In the IDE, in the main menu go to TOOLS/Entrian Attach: Configuration…, you’ll get the following window:

UPDATE: It’s important to enter the full path for the executable.  The Windows API for capturing process spawning is stupid – it only takes name of an executable, not a full path or wildchars.  Hence you can only specify names of executable files you want Entrian Attach to automatically attach to.  Obviously, when Visual Studio is running with Entrian Attach enabled and you start your regular browser, it will attach too.  I’ve added a toolbar button EntrianAttachEnableDisable to the standard toolbar for a quick switch and status visibility.

Other important option is to set Attach at process start when to “I’m not already debugging its exe”.  Otherwise, when firefox.exe is started externally, a shim process is inserted between the parent and a child process which breaks our security and other checks for expected pid == actual pid.  You would just end up with a MOZ_CRASH.

Note that the extension configuration and the on/off switch are per-solution.

Entrian Attach developer is very responsive.  We’ve already cooked the “When I’m not already debugging its exe” option to allow child process attaching without the inserted shim process, took just few days to release a fixed version.

Entrian Attach is a shareware with 10-day trial.  Then a single developer license is for $29.  There are volume discounts available.  Hence, since this is so super-useful, Mozilla could consider buying a multi-license.  Anyway, I believe it’s money very well spent!

The post Automatically attaching child and test-spawned Firefox processes in Visual Studio IDE appeared first on mayhemer's blog.

Mozilla Log Analyzer added basic network diagnostics

0
0

Mozilla Log Analyzer objects search results

Few weeks ago I’ve published Mozilla Log Analyzer (logan).  It is a very helpful tool itself when diagnosing our logs, but looking at the log lines doesn’t give answers about what’s wrong or right with network requests scheduling.  Lack of other tools, like Backtrack, makes informed decisions on many projects dealing with performance and prioritization hard or even impossible.  The same applies to verification of the changes.

Hence, I’ve added a simple network diagnostics to logan to get at least some notion of how we do with network request and response parallelization during a single page load.  It doesn’t track dependencies, by means of where from exactly a request originates, like which script has added the DOM node leading to a new request (hmm… maybe bug 1394369 will help?) or what all has to load to satisfy DOMContentLoaded or early first paint.  That’s not in powers of logan right now, sorry, and I don’t much plan investing time in it.  My time will be given to Backtrack.

But what logan can give us now is a breakdown of all requests being opened and active before and during a request you pick as your ‘hero request.’  May tell you what the concurrent bandwidth utilization was during the request in question, or what lower priority requests have been scheduled, been active or even done before the hero request.  What requests were blocking the socket where your request was finally dispatched on, and so on…

To obtain this diagnostic breakdown, use the current Nightly (at this time its Firefox 57) and capture logs from the parent AND also child processes with the following modules set:

MOZ_LOG=timestamp,sync,nsHttp:5,cache2:5,DocumentLeak:5,PresShell:5,DocLoader:5,nsDocShellLeak:5,RequestContext:5,LoadGroup:5,nsSocketTransport:5

(sync is optional, but you never know.)

Make sure you let the page you are analyzing to load, it’s OK to cancel too.  It’s best to close the browser then and only after that load all the produced logs (parent + children) to logan.  Find your ‘hero’ nsHttpChannel.  Expand it and then click its breadcrumb at the top of the search results.  There is a small [ diagnose ] button at the top.  Clicking it brings you to the breakdown page with number of sections listing the selected channel and also all concurrent channels according few – I found interesting – conditions.

This all is tracked on github and open to enhancements.

The post Mozilla Log Analyzer added basic network diagnostics appeared first on mayhemer's blog.

Firefox 57 delays requests to tracking domains

0
0

Firefox Quantum – version 57 – introduced number of changes to the network requests scheduler.  One of them is using data of the Tracking Protection database to delay load of scripts from tracking domains when possible during the time a page is actively loading and rendering – I call it tailing.

This has a positive effect on page load performance as we save some of the network bandwidth, I/O and CPU for loading and processing of images and scripts running on the site so the web page is complete and ready sooner.

Tracking scripts are not disabled, we only delay their load for few seconds when we can.  Requests are kept on hold only while there are site sub-resources still loading and only up to about 6 seconds.  The delay is engaged only for scripts added dynamically or as async.  Tracking images and XHRs are always delayed, as well as any request made by a tracking script.  This is legal according all HTML specifications and it’s assumed that well built sites will not be affected regarding functionality.

To make it more clear what we exactly do for site and tracking requests, this is how scheduling roughly looks like when tailing is engaged:

Firefox Quantum Tracker Tailing OK

And here with the tailing turned off:

Firefox Quantum Tracker Tailing OFF

This is of course not without problems.  For sites that are either not well built or their rendering is influenced by scripts from tracking domains there can be a visible or even functional regression.  Simply said, some sites need to be fixed to be able to adopt this change in scheduling.

One example is Google’s Page-Hiding Snippet, which may cause a web page to be blank for whole 4 seconds since the navigation start.  What happens?  Google’s A/B testing initially hides the whole web page with opacity: 0.  The test script first has to do its job to prepare the page for the test and only then it unhides the page content.  The test script is dynamically loaded by the analytics.js script.  Both the analytics.js and the test script are loaded from www.google-analytics.com, a tracking domain, for which we engage the tailing delay.  As the result the page is blank until one of the following wins: 4 seconds timeout elapses or we load both the scripts and execute them.  For a common user this appears as a performance drawback and not a win.

Other example can be a web page referring an API of an async tracking script from a sync script, which obviously is a race condition, since there is no guarantee that an async script loads before a sync script.  There is a real life example of such not-well-built site using a Twitter API – window.twttr.  The twttr object is simply not there when the site’s script calls on it.  An exception is thrown and the rest of the site script is not executed breaking some of the page’s functionality.  That effected web page worked before tailing just because Twitter’s servers were fast to respond and executed sooner than the site script using the window.twttr object.  Hence, worked only by a lucky accident.  Note that sites with such race condition issues are 100% broken also when opened in Private Browsing windows or when Tracking Protection with just the default list is turned on.

To conclude on how useful the tailing feature is – unfortunately, at the moment I don’t have enough data to provide (it’s on its way, though.)  So far testing was made mostly locally and on our Web Page Test internal testing infrastructure.  The effect was unfortunately just hidden in the overall noise, hence more scientific and wide testing needs to be done.

 

EDIT: Interesting reactions on www.bleepingcomputer.com and Hacker News.

 

(Note: few somewhat off-topic comments have been trashed in case you wonder why they don’t appear here ; I will only accept comments bringing a benefit to discussion of this feature and its issues, thanks for understanding)

The post Firefox 57 delays requests to tracking domains appeared first on mayhemer's blog.

Viewing all 43 articles
Browse latest View live




Latest Images