Reason for revert:
Breaks all windows bots:
https://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20debug/builds/6811
Original issue's description:
> [test] Remove local-tests from test262 archive and add to .isolate
>
> This might help fix the bots, which are broken in e.g.,
> https://build.chromium.org/p/tryserver.v8/builders/v8_mac_rel_ng_triggered/builds/14011
>
> The archive was added in order to transmit test262 tests more rapidly.
> It doesn't serve much of a purpose for local-tests. I naively added
> local-tests there out of symmetry. However, the BUILD.gn file does not
> regenerate an archive when files are only deleted and not added or
> changed. Since the performance concern is not present for the small
> volume of local-tests, this patch reverts to the more normal mechanism
> for sending over dependencies, with test262.isolate.
>
> R=adamk
>
> Review-Url: https://codereview.chromium.org/2643983002
> Cr-Commit-Position: refs/heads/master@{#42485}
> Committed: 9f545ea96fTBR=adamk@chromium.org,littledan@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2640223003
Cr-Commit-Position: refs/heads/master@{#42491}
This might help fix the bots, which are broken in e.g.,
https://build.chromium.org/p/tryserver.v8/builders/v8_mac_rel_ng_triggered/builds/14011
The archive was added in order to transmit test262 tests more rapidly.
It doesn't serve much of a purpose for local-tests. I naively added
local-tests there out of symmetry. However, the BUILD.gn file does not
regenerate an archive when files are only deleted and not added or
changed. Since the performance concern is not present for the small
volume of local-tests, this patch reverts to the more normal mechanism
for sending over dependencies, with test262.isolate.
R=adamk
Review-Url: https://codereview.chromium.org/2643983002
Cr-Commit-Position: refs/heads/master@{#42485}
This patch provides improved infrastructure for developing test262 tests
together with V8. It has three parts:
- The test262 test runner is updated to look for local versions of tests
in the /test/test262/local-tests directory, which mirrors
/test/test262/data. Additional tests can be added there and are run
together with tests from upstream. Upstream tests can be locally
updated by using the same name in local-tests; if a same-named test
exists, then only the local version will be run. The local-tests
directory is in the V8 repository, unlike the contents of the data
directory, so tests can be added in the same patch as something else.
- The tool /test/test262/upstream-local-tests.sh is added to create
a patch against the test262 respository based on a patch which changes
the local-tests directory.
- The tool /test/test262/prune-local-tests.sh is added to remove
redundant local tests on a test262 roll.
See design doc:
https://docs.google.com/document/d/16bj7AIDgZLv4WOsUEzQ5NzcEN9_xo095e88Pz8FC5rA/edit
Review-Url: https://codereview.chromium.org/2611793002
Cr-Commit-Position: refs/heads/master@{#42117}
TC-39 recently decided to remove the Python-based testing harness from the
Test262 project [1]. The code has been duplicated in a standalone project;
update V8's dependencies to fetch from that new location. This is based on
an earlier patch by Mike Pennisi.
[1] 2b9722db9b/es7/2016-05/may-25.md
BUG=v8:5078
Review-Url: https://codereview.chromium.org/2131743002
Cr-Commit-Position: refs/heads/master@{#37985}
This calls the action that archives test262 in gn. In gn
we can't specify an action output outside the product
directory. This works around it with an extra action
stamp file in the product directory, while the archive
remains in the test directory.
We don't want to generate the archive in the product
directory, as some legacy archiving scripts might include
it and it's too large. It should only be included in the
swarming tasks that are going to use it for testing.
BUG=chromium:474921
Review-Url: https://codereview.chromium.org/2034713005
Cr-Commit-Position: refs/heads/master@{#36731}
Apparently, the tarfile Python module spends a lot of time in
grp.getgrid for retrieving a piece information (the name of the
primary group) which we don't need anyway. There is no
proper way to disable these slow calls, but there's a workaround
which relies on the way in which grp (and pwd) is used.
In fact, pwd and grp are imported in this fashion:
try:
import grp, pwd
except ImportError:
grp = pwd = None
and then used with the following pattern [2]:
if grp:
try:
tarinfo.gname = grp.getgrgid(tarinfo.gid)[0]
except KeyError:
pass
By setting grp and pwd to None, thus skipping the calls, I was
able to achieve a 35x speedup on my workstation.
The user and group names are set to test262 when building the tar.
The downside to this approach is that we are relying on an
implementation detail, which is not in the public API.
However, the blamelist shows that the relevant bits of the module
have not been updated since 2003 [3], so we might as well assume
that the workaround will keep working, on cPython 2.x at least.
---
[1] https://hg.python.org/cpython/file/2.7/Lib/tarfile.py#l56
[2] https://hg.python.org/cpython/file/2.7/Lib/tarfile.py#l1933
[3] https://hg.python.org/cpython/rev/f9a5ed092660
BUG=chromium:535160
LOG=N
Review URL: https://codereview.chromium.org/1727773002
Cr-Commit-Position: refs/heads/master@{#34245}
This experimentally implements taring/untaring the test data
for test262 on the v8-side before test isolation and when
running the tests.
It archives on demand only if the tar is outdated compared
to the contained files. This comes with a cost of ~1s extra
to run gyp on linux and ~6s extra on windows. Ninja is
lightning fast afterwards in detecting changes. Also, we
archive only when test_isolation_mode is set and when
the test262_run target is required.
The archiving itself costs ~30s on all platforms. But as the
files will change seldom this shouldn't have a big impact.
Extraction on the test runner side is below 2s on mac and
linux. The speedup is enormous. Around 5 minutes were spent
on download on swarming slaves before, which is now only
a few seconds. So total test time for release (no variants),
e.g. goes from 8 to 3 minutes.
BUG=chromium:535160
LOG=n
Review URL: https://codereview.chromium.org/1713993002
Cr-Commit-Position: refs/heads/master@{#34155}
