Improve startup performance of isolates on windows

[GoogleCodeExporter]

On Windows, isolates that contain a lot of files (~5000) have a high fixed 
startup cost when invoked via run_isolated.py that's much higher than on Unix 
platforms. Please look at any recent jobs on these two testers:

http://build.chromium.org/p/chromium.gpu/builders/Linux%20Release%20(NVIDIA)
http://build.chromium.org/p/chromium.gpu/builders/Mac%20Retina%20Release

and compare to this one:

http://build.chromium.org/p/chromium.gpu/builders/Win7%20Release%20(NVIDIA)

The short-running tasks take on the order of 5 seconds to run on Linux and Mac, 
but take roughly a minute to run on Windows, due to the higher cost of setting 
up and tearing down Windows .LNK files compared to Unix symlinks. Improving the 
fixed cost here will improve machine utilization.

iannucci@ had some good ideas about how to address this the last time we 
discussed it.

Original issue reported on code.google.com by kbr@chromium.org on 26 Feb 2015 at 11:39

[GoogleCodeExporter]

I think at the time I suggested that we look into writing an isolatefs 
(probably using FUSE on linux, OSXFUSE on mac, and writing a MiniFilter driver 
on Windows).

However, I also think that would be a lot of work (esp. the minifilter on 
windows, even though minifilters are SUBSTANTIALLY easier to implement than the 
legacy filesystem drivers).

I would be interested in working this, but I also think that it's definitely 
NOT low-hanging fruit at this point :(. It also looks like it might be a pretty 
deep rabbit hole.

If anyone around the team has a penchant for writing filesystem drivers, this 
would be a neat project for them :P

Original comment by iannucci@chromium.org on 27 Feb 2015 at 2:38

[GoogleCodeExporter]

The advantage of the FUSE-like filesystem is that it would be trivial to create 
a lazy read-only filesystem which could be instructed to represent the content 
of a given isolated file via e.g. an ioctl.

The cache data would be safely protected away from the user code, and no 
massive symlink tree needs to be constructed. If we were feeling fancy, we 
could also back the filesystem with a temporary read/write filesystem so that 
write operations went to the temporary filesystem without disrupting the user 
code.

Since we can gate-keep the filesystem interaction, we could potentially get 
away with a small minifilter by having open operations block (to fetch the data 
from the network), and then simply issue a reparse to redirect to the 
underlying filesystem. This means we wouldn't even need to handle the actual 
data.

If we're particularly awesome, we could have a cross-platform go implementation 
of the cache management process and then just have the fuse/minifilter be a 
thin shim to pull levers on the cache manager.

Or I could be blowing smoke :)

Original comment by iannucci@chromium.org on 27 Feb 2015 at 2:50