hal/HalImpl.h
author Andrew McCreight <continuation@gmail.com>
Mon, 22 Apr 2019 16:34:51 +0000
changeset 470376 3073770e06f157040f4c64951b7e8425e1ad7bbe
parent 454354 5f4630838d46dd81dadb13220a4af0da9e23a619
permissions -rw-r--r--
Bug 1535403 - Take indirection into account for the CC optimizations for the outer window wrapper. r=peterv Most wrapper cached C++ objects are held alive by their wrapper. The cycle collector takes advantage of this in many classes and ignores the C++ object if the wrapper is marked black. However, this is not true for the outer window's wrapper. Instead, the outer window's wrapper keeps the inner window alive. The inner window usually keeps its outer window alive, but not after it has been unlinked. For reasons I do not yet understand, the outer window's wrapper can be kept alive after the inner window it is a proxy for is unlinked. This patch fixes the cycle collector optimization for the outer window by only applying it if the outer window still has a weak reference to the inner window, which it will until the inner no longer holds the outer alive. This in turn fixes, or at least helps fix, window leaks seen intermittently when the lifetime of outer windows and docshells are tied together. The code comment is based on a review comment by peterv. Differential Revision: https://phabricator.services.mozilla.com/D27981

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set sw=2 ts=8 et ft=cpp : */
/* This Source Code Form is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this file,
 * You can obtain one at http://mozilla.org/MPL/2.0/. */

#ifndef mozilla_HalImpl_h
#define mozilla_HalImpl_h

#ifdef MOZ_UNIFIED_BUILD
#  error Cannot use HalImpl.h in unified builds.
#endif

#define MOZ_HAL_NAMESPACE hal_impl
#undef mozilla_Hal_h
#undef mozilla_HalInternal_h
#include "Hal.h"
#include "HalInternal.h"
#undef MOZ_HAL_NAMESPACE

#endif  // mozilla_HalImpl_h