开源虚拟机 HHVM 4.109 版本发布

99

HHVM 4.109发布了! 这个版本标志着对4.103版本的支持已经结束;HHVM 4.104-4.108版本仍然受到支持,4.80和4.102 LTS版本也是如此。

HHVM是一个开源的虚拟机,旨在执行用Hack编写的程序。HHVM使用即时编译(JIT)的方法,在保持惊人的开发灵活性的同时,实现巨大的运行性能。HHVM支持Hack编程语言。我们正在快速发展,每天都在做改变,并经常发布。如果你注意到类型检查器或运行时的退步,请在发现时打开问题。

亮点

  • 如果在调用exit()后收到信号,HHVM不再崩溃。
  • ext_facts', ext_watchman'和基于watchman的本地自动加载器现在默认包含在构建中,如果构建系统中没有动态版本,则构建和静态链接libwatchmanclient。
  • 增加了 HH\enable_function_coverage()HH\collect_function_coverage();这些功能仅用于计算单元测试覆盖率,并且仅在 repo-authoritative 模式未启用,且 hhvm.enable_func_coverage ini 设置为 1 的情况下发挥作用。
  • 增加了 hhvm --check-repo;这可以用来验证 repo-authoritative repo 是用兼容的 HHVM 和兼容的选项构建的。作为CI/CD管道的调试工具,它可能是有用的,但它不是一个必要步骤。
  • 增加了 hhvm.notice_on_coerce_for_cmp 选项,对不同类型之间进行无效比较的情况提出通知。这个选项不控制已经有专用选项的情况,例如隐式的__toString()调用。

未来的变化

  • setlocale()中的几个错误正在被修复,导致可观察到的变化;这影响到Hack代码和HHVM中的C/C++扩展代码,因为HHVM用一个请求感知版本替换了libc的setlocale()
    • setlocale()现在将报告每个请求的初始locale为 "C";以前,HHVM报告的是空字符串,导致了不同的行为。
      • 使用uselocale()的C语言代码会检测到`"C "语言。
      • 使用setlocale()的C或Hack代码有时会检测到它是C,有时会从环境中手动推断,或者将它作为其他特殊的locale,例如无效的locale,或者ICU中的 "根 "locale。
    • 现在将locale设置为空字符串将从环境中推断出locale。例如,如果LC_ALL=en_US.UTF-8被设置,setlocale(LC_ALL, '')将设置locale为en_US.UTF-8,当通过setlocale()检索locale时,这将被指出。以前是这样。
      • 使用uselocale()的C代码将使用环境中的locale。
      • 使用setlocale()的C或Hack代码将无法区分这种状态和初始状态。
    • 总的来说,这些错误的修正使行为更有预见性,更接近于C/POSIX/Python的行为。值得注意的是,"C "的默认locale与PHP不同,后者默认使用环境locale。

基于Watchman的内置自动加载功能

内建自动加载现在可以使用了,但取决于系统上安装的 Watchman 守护程序。

每个存储库和每个进程(或全局)都需要设置;首先,必须在REPO_ROOT/.hhvmconfig.hdf中指定一个Watchman查询,例如。

自动加载 {
  查询 = {"表达式": ["allof", ["type", "f"], ["suffix", ["anyof", "hack", "php"]], ["not", ["anyof", ["dirname", ".hg"], ["dirname", ".git"] , ["dirname", ".svn" ]]]]}
}

此外,需要在命令行或配置文件中指定以下选项。

  • hhvm.autoload.enabled=true
  • hhvm.autoload.db.path=foo/autoload-%{euid}-%{schema}.db

%{euid}%{schema}占位符是可选的,如果存在,会自动替换为当前有效的用户ID和HHVM模式版本--当HHVM有不兼容的变化时,模式应该改变,并使用新文件。

正确的配置可以通过以下方式进行验证

  • 检查HH\Facts\enabled()的返回值。
  • 在需要自动加载的定义上调用class_exists()function_exists()在你的入口处。

当使用内置的自动加载器时,没有必要初始化单独的自动加载器,如hhvm-autoload工具;例如,没有必要require('vendor/autoload.hack')或调用Facebook\AutoloadMap\initialize()

我们期望未来的HHVM版本能够。

  • 减少所需的配置量
  • 继续支持Watchman,但不要求它;Watchman可能会继续被推荐,特别是对于大型项目来说

HHVM 4.109 is released! This release marks the end of support for 4.103; HHVM 4.104–4.108 remain supported, as do the 4.80 and 4.102 LTS releases.

Highlights

  • HHVM no longer crashes if a signal is received after calling exit()
  • ext_factsext_watchman and the watchman-based native autoloader are now included in builds by default, building and statically linking libwatchmanclient if a dynamic version is not available in the build system.
  • added HH\enable_function_coverage() and HH\collect_function_coverage(); these are intended for calculating unit test coverage only, and only function if repo-authoritative mode is not enabled, and the hhvm.enable_func_coverage ini setting is 1.
  • added hhvm --check-repo; this can be used to verify that a repo-authoritative repo was built with a compatible HHVM and with compatible options. It may be useful as a debugging tool for CI/CD pipelines, but it is not a necessary step.
  • added the hhvm.notice_on_coerce_for_cmp option, raising notices for cases where invalid comparisons are made between different types. This option does not control cases where there were already dedicated options, such as implicit __toString() calls.

Future Changes

  • Several bugs are being fixed in setlocale(), leading to observerable changes; this affects both Hack code, and C/C++ extension code in HHVM, as HHVM replaces the libc setlocale() with a request-aware version.
    • The initial locale for each request will now be reported as "C" by setlocale(); previously, HHVM reported the empty string, leading to differing behavior:
      • C code using uselocale() would detect the "C" locale
      • C or Hack code using setlocale() would sometimes detect it as C, sometimes manually infer it from the environment, or use it as some other special locale, eg an invalid locale, or the ‘root’ locale in ICU.
    • Setting the locale to the empty string will now infer the locale from the environment. For example, if LC_ALL=en_US.UTF-8 is set, setlocale(LC_ALL, '') will set the locale to en_US.UTF-8, and this will be indicated when retrieving the locale via setlocale(). Previously:
      • C code using uselocale() would use the locale from the environment
      • C or Hack code using setlocale() would not be able to distinguish this state from the initial state
    • Overall, these bugfixes make the behavior more predicatable and closer to C/POSIX/Python behavior. Notably, the default locale of "C" differs to PHP, which defaults to using the environment locale.

Watchman-based Built-In Autoloading

Built-in autoloading is now avaiable, but depends on the Watchman daemon being installed on your system.

Both per-repository and per-process (or global) settings are required; first, a Watchman query must be specified in REPO_ROOT/.hhvmconfig.hdf, e.g.:

Autoload {
  Query = {"expression": ["allof", ["type", "f"], ["suffix", ["anyof", "hack", "php"]], ["not",["anyof",["dirname",".hg"],["dirname",".git"],["dirname",".svn"]]]]}
}

Additionally, the following options need to be specified on the command line or in a configuration file:

  • hhvm.autoload.enabled=true
  • hhvm.autoload.db.path=foo/autoload-%{euid}-%{schema}.db

The %{euid} and %{schema} placeholders are optional, and if present, automatically replaced with the current effective user ID and HHVM schema version – when there are incompatible changes to HHVM, the schema should change and a new file should be used.

Correct configuration can be verified by:

  • checking the return value of HH\Facts\enabled()
  • calling class_exists() or function_exists() in your entrypoint on a definition that requires autoloading

When using the built-in autoloader, it is not necessary to initialize separate autoloaders such as the hhvm-autoload tool; for example, it is not necessary to require('vendor/autoload.hack') or to call Facebook\AutoloadMap\initialize().

We expect future versions of HHVM to:

  • reduce the amount of configuration required
  • continue to support Watchman, but not require it; Watchman will likely remain recommended, especially for larger projects