Closed Bug 1490427 Opened 3 years ago Closed 2 years ago

jsshell bench runs v8 shell as 'd8', AWFY custom built d8 with is_debug=false


(Testing :: Raptor, enhancement)

Not set


(firefox66 fixed)

Tracking Status
firefox66 --- fixed


(Reporter: jmaher, Assigned: sparky)




(1 file)

we need to build a custom d8 version instead of the prebuilt version.

We should be able to do this with:

you can see a comment referencing the old build process:

and references to some build settings:

I suspect we can build a docker image that has all the tools for a build and can build a simple script that runs and builds d8 with an upload as an artifact.
In the shorter term, it would be easier to just build 'd8' locally and upload that to the perf-automation repo (to be used in the fetch task).

I agree having automation do the build is more ideal, but it also seems like a waste to re-build the exact same version of d8 over and over again. I guess we can figure out the taskgraph magic to re-use the same artifact over and over again so we don't always need to re-build it. I think implementing this as a "toolchain" task might be a good fit, but I would have to do some investigation to be sure.
Just noting that I did originally try to build 'd8' locally, but their build process doesn't support Fedora, so that's why I ended up using the pre-built binary.
so I think the best bet here is to create a docker image that does all the custom building- then we can download that locally as well as use it in CI.  I would prefer that over figuring out how to get all the bits installed on my local windows machine.
here is an example docker file used to build d8:

I need to figure out if there is an example build script I could use to add to the tree so we could:
1) create a new build job in-tree for v8, ideally using an existing dockerfile or a new one
2) upload the output file as an artifact that we can use

:ted, do you have suggestions on where I could start looking?
Flags: needinfo?(ted)
Blocks: 1488689
If you look at our existing toolchain tasks we have a bunch that build random third-party code. As an arbitrary example, here's where we build libdmg for the dmg tools for our mac cross-builds:

It calls into this script which is pretty straightforward:

Toolchain tasks all run in the toolchain-build Docker image which is defined here:

Odds are it already has everything you need to build v8, we're building a lot of projects in that image.
Flags: needinfo?(ted)
the docker image from comment 4 is outdated, but I still think with little effort we can reuse a toolchain build.  The docs have been updated:
I've spent some time looking into this and the toolchain-build uses debian-7 which has some missing packages that seem to primarily exist for debian-8 (jessie) and debian-9 (stretch) with no existing backports:


Here's a try run that shows this:

This error occurs when I follow the instructions here [1].
I'm going to test the instructions here [1] now to see if those commands along with the options mentioned here [2] would solve this. (Maybe [1] is building things we don't need). If this doesn't work, and we still have missing packages, we could either use a debian-8/9 docker image for this or perhaps fallback onto an older v8 version which might not require them (I imagine that there are other options as well).

Assignee: nobody → gmierz2
(In reply to Greg Mierzwinski [:sparky] from comment #7)
> This error occurs when I follow the instructions here [1].
> I'm going to test the instructions here [2] now to see if those commands
> along with the options mentioned here [3] would solve this. (Maybe [1] is

Mixed up the reference numbers - this quote is the corrected version.
I've got a successful custom v8 build here:

It's not possible to build this on debian7 so I made a debian9-base docker image for the custom-v8 task to do this. (More specifically, `libwayland-egl1-mesa` is a common requirement in the build dependencies but is not available in debian7). Also, both methods I mentioned in comment 7 ([1], and [2]) requires us to have installed the build dependencies so using one method instead of the other didn't help.

After I add the extra build settings and upload the artifact in the patch, I'll post a patch for review.
:jmaher, is there a specific OS/CPU that we should be targeting in this build or would it be used for more than just one variation like the AWFY builder is set up [1]?

Flags: needinfo?(jmaher)
we are targeting linux only- but writing code to be more generic is a good idea.

using debian9 is just fine from my perspective- do we have a try push or evidence that the generated v8 build is able to run the shell tests?
Flags: needinfo?(jmaher)
Here's a test run that has the jsshell tests use the d8 version that was built on debian9:

This is the task which built the d8 that was used:
This patch adds a toolchain task for building d8 with customized build settings and uses it in jsshell benchmark tests. A customized image with a debian9-base ('custom-v8') is added by this patch as well and is required to build the tool.
For the patch that was submitted for review, here's a test run with it:

The docker image was built in this test run (the broken tests have been fixed):
Blocks: 1514087
Pushed by
Build and use custom d8 from a toolchain task. r=jmaher,ahal
This should be fixed in the latest patch, I can't reproduce this failure on try but I can remove the file which is causing the issue. Here's a test run using this patch:
Flags: needinfo?(gmierz2)
Pushed by
Build and use custom d8 from a toolchain task. r=jmaher,ahal
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
Depends on: 1519816
You need to log in before you can comment on or make changes to this bug.