v8/test/mjsunit/compiler/regress-905555.js

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

28 lines
704 B
JavaScript
Raw Normal View History

// Copyright 2018 the V8 project authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
[compiler][test] Give tests control over finalization Some tests want to invalidate part of the VM state after an optimization has consumed the old state but before the code is installed. The existing mechanism for this is --block-concurrent-recompilation and %UnblockConcurrentRecompilation(). The former suspends optimization right after PrepareJob, before the background ExecuteJob phase. The intrinsic can then be used to unblock it again. This was good enough so far because the main "consume" work used to happen on the main thread. With concurrent inlining this is no longer true and we need something else. This CL introduces three intrinsics: %DisableOptimizationFinalization turns off automatic finalization of background optimizations. %FinalizeOptimization() can then be called at an appropriate time to manually finalize (and thus install) the code and reenable automatic finalization. In case one wants to perform some action on the main thread after the concurrent optimization has finished but before it is finalized, one can do so with the help of %WaitForBackgroundOptimization() (see tests). In a followup CL I'm removing the old mechanism since it now seems redundant. Bug: v8:12041, v8:7790 Change-Id: Ib7195789105922eb7e4bff86dc5bc11e96a4f97b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071400 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#76190}
2021-08-10 09:13:13 +00:00
// Flags: --allow-natives-syntax --noalways-opt
global = 1;
function boom(value) {
return global;
}
%PrepareFunctionForOptimization(boom);
assertEquals(1, boom());
assertEquals(1, boom());
[compiler][test] Give tests control over finalization Some tests want to invalidate part of the VM state after an optimization has consumed the old state but before the code is installed. The existing mechanism for this is --block-concurrent-recompilation and %UnblockConcurrentRecompilation(). The former suspends optimization right after PrepareJob, before the background ExecuteJob phase. The intrinsic can then be used to unblock it again. This was good enough so far because the main "consume" work used to happen on the main thread. With concurrent inlining this is no longer true and we need something else. This CL introduces three intrinsics: %DisableOptimizationFinalization turns off automatic finalization of background optimizations. %FinalizeOptimization() can then be called at an appropriate time to manually finalize (and thus install) the code and reenable automatic finalization. In case one wants to perform some action on the main thread after the concurrent optimization has finished but before it is finalized, one can do so with the help of %WaitForBackgroundOptimization() (see tests). In a followup CL I'm removing the old mechanism since it now seems redundant. Bug: v8:12041, v8:7790 Change-Id: Ib7195789105922eb7e4bff86dc5bc11e96a4f97b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071400 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#76190}
2021-08-10 09:13:13 +00:00
%DisableOptimizationFinalization();
%OptimizeFunctionOnNextCall(boom, "concurrent");
assertEquals(1, boom());
[compiler][test] Give tests control over finalization Some tests want to invalidate part of the VM state after an optimization has consumed the old state but before the code is installed. The existing mechanism for this is --block-concurrent-recompilation and %UnblockConcurrentRecompilation(). The former suspends optimization right after PrepareJob, before the background ExecuteJob phase. The intrinsic can then be used to unblock it again. This was good enough so far because the main "consume" work used to happen on the main thread. With concurrent inlining this is no longer true and we need something else. This CL introduces three intrinsics: %DisableOptimizationFinalization turns off automatic finalization of background optimizations. %FinalizeOptimization() can then be called at an appropriate time to manually finalize (and thus install) the code and reenable automatic finalization. In case one wants to perform some action on the main thread after the concurrent optimization has finished but before it is finalized, one can do so with the help of %WaitForBackgroundOptimization() (see tests). In a followup CL I'm removing the old mechanism since it now seems redundant. Bug: v8:12041, v8:7790 Change-Id: Ib7195789105922eb7e4bff86dc5bc11e96a4f97b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071400 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#76190}
2021-08-10 09:13:13 +00:00
%WaitForBackgroundOptimization();
this.__defineGetter__("global", () => 42);
[compiler][test] Give tests control over finalization Some tests want to invalidate part of the VM state after an optimization has consumed the old state but before the code is installed. The existing mechanism for this is --block-concurrent-recompilation and %UnblockConcurrentRecompilation(). The former suspends optimization right after PrepareJob, before the background ExecuteJob phase. The intrinsic can then be used to unblock it again. This was good enough so far because the main "consume" work used to happen on the main thread. With concurrent inlining this is no longer true and we need something else. This CL introduces three intrinsics: %DisableOptimizationFinalization turns off automatic finalization of background optimizations. %FinalizeOptimization() can then be called at an appropriate time to manually finalize (and thus install) the code and reenable automatic finalization. In case one wants to perform some action on the main thread after the concurrent optimization has finished but before it is finalized, one can do so with the help of %WaitForBackgroundOptimization() (see tests). In a followup CL I'm removing the old mechanism since it now seems redundant. Bug: v8:12041, v8:7790 Change-Id: Ib7195789105922eb7e4bff86dc5bc11e96a4f97b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071400 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#76190}
2021-08-10 09:13:13 +00:00
%FinalizeOptimization();
// boom should be deoptimized because the global property cell has changed.
[compiler][test] Give tests control over finalization Some tests want to invalidate part of the VM state after an optimization has consumed the old state but before the code is installed. The existing mechanism for this is --block-concurrent-recompilation and %UnblockConcurrentRecompilation(). The former suspends optimization right after PrepareJob, before the background ExecuteJob phase. The intrinsic can then be used to unblock it again. This was good enough so far because the main "consume" work used to happen on the main thread. With concurrent inlining this is no longer true and we need something else. This CL introduces three intrinsics: %DisableOptimizationFinalization turns off automatic finalization of background optimizations. %FinalizeOptimization() can then be called at an appropriate time to manually finalize (and thus install) the code and reenable automatic finalization. In case one wants to perform some action on the main thread after the concurrent optimization has finished but before it is finalized, one can do so with the help of %WaitForBackgroundOptimization() (see tests). In a followup CL I'm removing the old mechanism since it now seems redundant. Bug: v8:12041, v8:7790 Change-Id: Ib7195789105922eb7e4bff86dc5bc11e96a4f97b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071400 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#76190}
2021-08-10 09:13:13 +00:00
assertUnoptimized(boom);
assertEquals(42, boom());