Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(273)

Issue 427803003: Oilpan: Build fix after r179102 (Closed)

Created:
6 years, 4 months ago by haraken
Modified:
6 years, 4 months ago
Reviewers:
oilpan-reviews, tkent, Yuki
CC:
blink-reviews, blink-reviews-css, ed+blinkwatch_opera.com, dglazkov+blink, apavlov+blink_chromium.org, darktears, rune+blink, rwlbuis
Project:
blink
Visibility:
Public.

Description

Oilpan: Build fix after r179102 It looks like r179102 increased sizeof(CSSValue) only in Windows builds with Oilpan enabled. I don't know why. At the moment, this CL fixes the size expectation and fixed the compile error. TBR=yukishiino@chromium.org Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=179158

Patch Set 1 #

Total comments: 1
Unified diffs Side-by-side diffs Delta from patch set Stats (+1 line, -1 line) Patch
M Source/core/css/CSSValue.cpp View 1 chunk +1 line, -1 line 1 comment Download

Messages

Total messages: 8 (0 generated)
haraken
6 years, 4 months ago (2014-07-29 16:27:42 UTC) #1
haraken
Committed patchset #1 manually as r179158 (presubmit successful).
6 years, 4 months ago (2014-07-29 16:28:33 UTC) #2
haraken
shiino-san: Would you take a look at why r179102 increased sizeof(CSSValue) only in Windows builds ...
6 years, 4 months ago (2014-07-29 16:29:39 UTC) #3
tkent
https://codereview.chromium.org/427803003/diff/1/Source/core/css/CSSValue.cpp File Source/core/css/CSSValue.cpp (right): https://codereview.chromium.org/427803003/diff/1/Source/core/css/CSSValue.cpp#newcode61 Source/core/css/CSSValue.cpp:61: struct SameSizeAsCSSValue : public RefCountedWillBeGarbageCollectedFinalized<SameSizeAsCSSValue>, public ScriptWrappableBase { We ...
6 years, 4 months ago (2014-07-29 23:00:01 UTC) #4
haraken
On 2014/07/29 23:00:01, tkent wrote: > https://codereview.chromium.org/427803003/diff/1/Source/core/css/CSSValue.cpp > File Source/core/css/CSSValue.cpp (right): > > https://codereview.chromium.org/427803003/diff/1/Source/core/css/CSSValue.cpp#newcode61 > ...
6 years, 4 months ago (2014-07-29 23:16:51 UTC) #5
Yuki
On 2014/07/29 16:29:39, haraken wrote: > shiino-san: Would you take a look at why r179102 ...
6 years, 4 months ago (2014-07-30 08:16:28 UTC) #6
zerny-chromium
On 2014/07/30 08:16:28, Yuki wrote: > On 2014/07/29 16:29:39, haraken wrote: > > shiino-san: Would ...
6 years, 4 months ago (2014-07-30 08:44:45 UTC) #7
Yuki
6 years, 4 months ago (2014-07-30 09:23:46 UTC) #8
Message was sent while issue was closed.
On 2014/07/30 08:44:45, zerny-chromium wrote:
> On 2014/07/30 08:16:28, Yuki wrote:
> > On 2014/07/29 16:29:39, haraken wrote:
> > > shiino-san: Would you take a look at why r179102 increased
sizeof(CSSValue)
> > only
> > > in Windows builds with Oilpan enabled?
> > > 
> > > The compile error log is here:
> > >
> >
>
http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Win%20Oilpan%20...
> > 
> > I found the cause: VC++ (including the latest VC++ 2013) doesn't support
EBCO
> > (Empty Base Class Optimization).
> > For details, see
> >
>
http://social.msdn.microsoft.com/forums/vstudio/en-US/504c6598-6076-4acf-96b6...
> > This article best describes the issue, and also introduces an workaround.
> > 
> > I think we have at least two options here.
> > 
> > 1) Oilpan reduces the size of CSSValue from 8 to 4 bytes because we no
longer
> > need a reference counter in CSSValue, we could leave this issue as-is until
> VC++
> > supports EBCO.  The size of CSSValue is 8 bytes if it derives
> > ScriptWrappableBase regardless of Oilpan.  It's enough small, isn't it?
> > 
> > 2) Does a workaround as introduced in the above article.
> > class ScriptWrappableGarbageCollected : public
> > GarbageCollected<ScriptWrappableGarbageCollected>, public ScriptWrappable
{};
> > class CSSValue : public ScriptWrappableGarbageCollected { ... };
> > Then, CSSValue has only one direct base class which is empty, so it won't
> > increase the size of CSSValue.
> 
> Although not pretty, I would vote for solution (2). It would eliminate
#if-defs
> since it works on all compilers without overhead. Just make sure to have a
good
> explanation preceding the dummy-class definition.

Sent out http://crrev.com/423383003 with solution 2.

Powered by Google App Engine
This is Rietveld 408576698