Remove assertion in SetResourceConstraints.

Remove assertion in SetResourceConstraints.

BUG=312233
R=rmcilroy@chromium.org

Committed: https://code.google.com/p/v8/source/detail?r=17416

[titzer, 2013-10-28 08:47:55]

This ASSERT fails when debugging a chromium build with content_shell.

[Sven Panne, 2013-10-28 08:57:27]

DBC: Please open a bug and assign it to you, so we don't forget to re-enable the
assertion when Chrome is fixed. The assertion itself is valuable and there for a
reason... :-)

[rmcilroy, 2013-10-28 09:30:11]

On 2013/10/28 08:47:55, titzer wrote:
> This ASSERT fails when debugging a chromium build with content_shell.

I have a CL which fixes this (https://codereview.chromium.org/26868004/), but
before landing it I also need to land a change to avoid doing a call to
platform-posix OS::TotalPhysicalMemory from within the Chrome Sandbox, which
will fail with an ASSERT even after disabling this ASSERT.  I will send out a CL
which temporarily disables the call to OS::TotalPhysicalMemory (since the proper
fix to that is going to involve a large change in Blink and Chrome), so that I
can land both this and https://codereview.chromium.org/26868004/ today and fix
the failing asserts.  Depending upon what you need this for, maybe you don't
need to disable this ASSERT and can wait for these fixes?

[rmcilroy, 2013-10-28 15:53:33]

On 2013/10/28 09:30:11, rmcilroy wrote:
> On 2013/10/28 08:47:55, titzer wrote:
> > This ASSERT fails when debugging a chromium build with content_shell.
> 
> I have a CL which fixes this (https://codereview.chromium.org/26868004/), but
> before landing it I also need to land a change to avoid doing a call to
> platform-posix OS::TotalPhysicalMemory from within the Chrome Sandbox, which
> will fail with an ASSERT even after disabling this ASSERT.  I will send out a
CL
> which temporarily disables the call to OS::TotalPhysicalMemory (since the
proper
> fix to that is going to involve a large change in Blink and Chrome), so that I
> can land both this and https://codereview.chromium.org/26868004/ today and fix
> the failing asserts.  Depending upon what you need this for, maybe you don't
> need to disable this ASSERT and can wait for these fixes?

According to Jakob, ASSERTS are being re-enabled in debug Chromium with this
roll, and I can't land https://codereview.chromium.org/26868004/ until r17415
also lands in this roll, so I think you will need to land this CL temporarily.
Add a TODO(rmcilroy), or bug and I'll revert this change once 26868004 has
landed in Blink.

[titzer, 2013-10-28 16:07:21]

On 2013/10/28 15:53:33, rmcilroy wrote:
> On 2013/10/28 09:30:11, rmcilroy wrote:
> > On 2013/10/28 08:47:55, titzer wrote:
> > > This ASSERT fails when debugging a chromium build with content_shell.
> > 
> > I have a CL which fixes this (https://codereview.chromium.org/26868004/),
but
> > before landing it I also need to land a change to avoid doing a call to
> > platform-posix OS::TotalPhysicalMemory from within the Chrome Sandbox, which
> > will fail with an ASSERT even after disabling this ASSERT.  I will send out
a
> CL
> > which temporarily disables the call to OS::TotalPhysicalMemory (since the
> proper
> > fix to that is going to involve a large change in Blink and Chrome), so that
I
> > can land both this and https://codereview.chromium.org/26868004/ today and
fix
> > the failing asserts.  Depending upon what you need this for, maybe you don't
> > need to disable this ASSERT and can wait for these fixes?
> 
> According to Jakob, ASSERTS are being re-enabled in debug Chromium with this
> roll, and I can't land https://codereview.chromium.org/26868004/ until r17415
> also lands in this roll, so I think you will need to land this CL temporarily.
> Add a TODO(rmcilroy), or bug and I'll revert this change once 26868004 has
> landed in Blink.

Ok, I will need an LGTM for this operation.

[rmcilroy, 2013-10-28 16:14:39]

lgtm

Thanks Ben!

[titzer, 2013-10-28 16:17:49]

Committed patchset #3 manually as r17416.