v8/test/mjsunit/compiler/concurrent-invalidate-transition-map.js

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

74 lines
2.9 KiB
JavaScript
Raw Normal View History

// Copyright 2013 the V8 project authors. All rights reserved.
// Redistribution and use in source and binary forms, with or without
// modification, are permitted provided that the following conditions are
// met:
//
// * Redistributions of source code must retain the above copyright
// notice, this list of conditions and the following disclaimer.
// * Redistributions in binary form must reproduce the above
// copyright notice, this list of conditions and the following
// disclaimer in the documentation and/or other materials provided
// with the distribution.
// * Neither the name of Google Inc. nor the names of its
// contributors may be used to endorse or promote products derived
// from this software without specific prior written permission.
//
// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
// "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
// OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
[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 --concurrent-recompilation --no-always-opt
if (!%IsConcurrentRecompilationSupported()) {
print("Concurrent recompilation is disabled. Skipping this test.");
quit();
}
function new_object() {
var o = {};
o.a = 1;
o.b = 2;
return o;
}
function add_field(obj) {
// Assign twice to make the field non-constant.
obj.c = 0;
obj.c = 3;
}
%PrepareFunctionForOptimization(add_field);
var obj1 = new_object();
var obj2 = new_object();
add_field(obj1);
add_field(obj2);
[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(add_field, "concurrent");
var o = new_object();
// Kick off recompilation.
add_field(o);
// Invalidate transition map after compile graph has been created.
[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();
o.c = 2.2;
assertUnoptimized(add_field);
// Sync with background thread to conclude optimization that bailed out.
[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();
if (!%IsDictPropertyConstTrackingEnabled()) {
// TODO(v8:11457) Currently, we cannot inline property stores if there is a
// dictionary mode prototype on the prototype chain. Therefore, if
// v8_dict_property_const_tracking is enabled, the optimized code only
// contains a call to the IC handler and doesn't get invalidated when the
// transition map changes.
[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(add_field);
}
// Clear type info for stress runs.
%ClearFunctionFeedback(add_field);