Possible upgrade of V8

[y4r9]

Dear ArangoDB team,

while working with the dev branch of ArangoDB I noticed that the upcoming version 3.9 will include the updated version of RocksDB (6.26). Although not necessary, I was wondering if you are also considering to update the V8, especially since it has a very rapid release cycle and older versions fall out of support fast. With minor modifications to the code (arangodb), I was able to migrate to version 9.4.146.24 on Ubuntu 20.04. However, the new versions of V8 are usually built with Google’s depot tools (gn or gm) instead of gyp which also requires the adaptation of the CMake file to the new build system. When replacing some deprecated functions/methods with their successors the build passes all tests executed with arangodbtests. While I do not have the possibilities to test on Windows, Mac and ARM it seems feasible for someone more familiar with these platforms to easily add the necessary changes. One problem I encountered was that V8 is typically built with top of the branch Clang and linked against its libc++ which breaks the static linking with the native libc++ or libstdc++. However, when compiling ArangoDB with gcc and linking V8 against the native libstdc++ (configurable via build params) everything seems to work. I am not sure what would happen on platforms like Mac where Clang/LLVM is the native toolchain. While the changes I made do not have stable release quality, I would be happy to share them as inspiration in case you would be interested.

Thank you for your time and effort.

[y4r9]

For those interested, I created a fork on github and added my changes in the update-V8 branch (see: https://github.com/y4r9/arangodb/tree/update-V8 )

[Wilfried Gösgens]

Hi,

the Problem about GN is, that it aligns very bad with our build toolchain since the source (at least when we checked last) wasn't available to better integrate it, so running GN would not easily work for us.

Another big roadblock is this long standing ninja issue: https://github.com/ninja-build/ninja/issues/1139 which will result in either building with parallellity of 1, or building with more processes at once than the host can bear. This is very bad for CI purposes and general development work as you could think. Either wait not utilizing the resources of your machines, or have your machine being run into the ground.

The solution we found way back then was to use the V8 branch the nodejs team maintains including gyp files - so no gn, no ninja - no cry. The nodejs team decided to keep going with gyp since many of their ecosystem nowadays also leans on it. They also maintain V8 gyp files, which in an upgrade case only have to be sync'ed with ours.

Its definitely great that you adjusted the ArangoDB parts, most probably that will be most of the work sync'ing in a later V8 from nodejs into ArangoDB.

Cheers,

Willi