relnote: QUIC streamable frames can now use a freelist for their packet buffers, Guarded by gfe2_fe…

relnote: QUIC streamable frames can now use a freelist for their packet buffers, Guarded by gfe2_feature_flag_use_stream_frame_freelist.

This is sufficiently different from the original version of the QUIC
stream buffer freelist to not be a rollback anymore. Notably, the
freelist now
releases memory opportunistically and can release all of its memory if
the flag
is disabled.

Additionally, the extra cache miss when reading the metadata out of the
allocation has been removed by falling back to a (very fast) linear
search of
the initialized Regions.

Merge internal change: 111443217

BUG=

[Zhongyi Shi, 2016-01-08 23:05:45]

zhongyi@chromium.org changed reviewers:
+ jdorfman@google.com, rch@chromium.org

[Zhongyi Shi, 2016-01-08 23:05:45]

Having issues for porting this cl:

A lot of tests crashed due to memory free. A sample stacktrace is as follows:
[ RUN      ] Version/QuicNetworkTransactionTest.QuicProxyWithCert/4
[27986:27986:0108/145834:2225147252306:FATAL:quic_buffer_pool.h(327)] Freeing
0x3eaf6f761750 with 0 unfreed allocations.
#0 0x00000345917e base::debug::StackTrace::StackTrace()
#1 0x00000349128f logging::LogMessage::~LogMessage()
#2 0x0000010b304c net::QuicBufferPool<>::Region::~Region()
#3 0x000001cde455 std::array<>::~array()
#4 0x000001cdd8d1 net::QuicBufferPool<>::~QuicBufferPool()
#5 0x000001cdc623 net::QuicConnectionHelper::~QuicConnectionHelper()
#6 0x000001cdc659 net::QuicConnectionHelper::~QuicConnectionHelper()
#7 0x0000005fa46f std::default_delete<>::operator()()
#8 0x0000005fa431 base::internal::scoped_ptr_impl<>::reset()
#9 0x000001237869 base::internal::scoped_ptr_impl<>::~scoped_ptr_impl()
#10 0x000001237725 scoped_ptr<>::~scoped_ptr()
#11 0x0000020fda1d net::QuicStreamFactory::~QuicStreamFactory()
#12 0x00000201f445 net::HttpNetworkSession::~HttpNetworkSession()
#13 0x000000873d3b std::default_delete<>::operator()()
#14 0x000000873d01 base::internal::scoped_ptr_impl<>::reset()
#15 0x000000873cb9 base::internal::scoped_ptr_impl<>::~scoped_ptr_impl()
#16 0x000000873695 scoped_ptr<>::~scoped_ptr()
#17 0x00000125d3d4
net::test::QuicNetworkTransactionTest::~QuicNetworkTransactionTest()
#18 0x00000125bc15
net::test::QuicAltSvcCertificateVerificationTest::~QuicAltSvcCertificateVerificationTest()
#19 0x00000125bc39
net::test::QuicAltSvcCertificateVerificationTest::~QuicAltSvcCertificateVerificationTest()
#20 0x00000060962b base::RefCountedThreadSafe<>::DeleteInternal()
#21 0x000003625a0a testing::internal::HandleSehExceptionsInMethodIfSupported<>()
#22 0x00000361742e testing::internal::HandleExceptionsInMethodIfSupported<>()
#23 0x00000360cc40 testing::TestInfo::Run()
#24 0x00000360d19a testing::TestCase::Run()
#25 0x00000361252c testing::internal::UnitTestImpl::RunAllTests()
#26 0x00000362a18a testing::internal::HandleSehExceptionsInMethodIfSupported<>()
#27 0x000003618ace testing::internal::HandleExceptionsInMethodIfSupported<>()
#28 0x0000036121cf testing::UnitTest::Run()
#29 0x000002a43051 RUN_ALL_TESTS()
#30 0x000002a420ff base::TestSuite::Run()
#31 0x00000091e849 base::internal::RunnableAdapter<>::Run()
#32 0x000000b0717f
_ZN4base8internal12InvokeHelperILb0EvNS0_15RunnableAdapterIMN3net31SQLitePersistentCookieStoreTestEFvvEEENS0_8TypeListIJPNS3_58SQLitePersistentCookieStoreTest_TestLoadCookiesForKey_TestEEEEE8MakeItSoES7_SA_
#33 0x0000018dc7c8
_ZN4base8internal7InvokerINS_13IndexSequenceIJLm0EEEENS0_9BindStateINS0_15RunnableAdapterIMNS_9TestSuiteEFivEEEFiPS6_EJNS0_17UnretainedWrapperI12NetTestSuiteEEEEENS0_8TypeListIJNS0_12UnwrapTraitsISE_EEEEENS0_12InvokeHelperILb0EiS9_NSG_IJPSD_EEEEEFivEE3RunEPNS0_13BindStateBaseE
#34 0x00000074008e base::Callback<>::Run()
#35 0x000002a7cc96 base::(anonymous namespace)::LaunchUnitTestsInternal()
#36 0x000002a7cafc base::LaunchUnitTests()
#37 0x0000018dc56a main
#38 0x7efe7a4a7ec5 __libc_start_main
#39 0x0000005d2035 <unknown>

[Ryan Hamilton, 2016-01-08 23:52:38]

On 2016/01/08 23:05:45, Zhongyi Shi wrote:
> Having issues for porting this cl:
> 
> A lot of tests crashed due to memory free. A sample stacktrace is as follows:
> [ RUN      ] Version/QuicNetworkTransactionTest.QuicProxyWithCert/4
> [27986:27986:0108/145834:2225147252306:FATAL:quic_buffer_pool.h(327)] Freeing
> 0x3eaf6f761750 with 0 unfreed allocations.
> #0 0x00000345917e base::debug::StackTrace::StackTrace()
> #1 0x00000349128f logging::LogMessage::~LogMessage()
> #2 0x0000010b304c net::QuicBufferPool<>::Region::~Region()
> #3 0x000001cde455 std::array<>::~array()
> #4 0x000001cdd8d1 net::QuicBufferPool<>::~QuicBufferPool()
> #5 0x000001cdc623 net::QuicConnectionHelper::~QuicConnectionHelper()
> #6 0x000001cdc659 net::QuicConnectionHelper::~QuicConnectionHelper()
> #7 0x0000005fa46f std::default_delete<>::operator()()
> #8 0x0000005fa431 base::internal::scoped_ptr_impl<>::reset()
> #9 0x000001237869 base::internal::scoped_ptr_impl<>::~scoped_ptr_impl()
> #10 0x000001237725 scoped_ptr<>::~scoped_ptr()
> #11 0x0000020fda1d net::QuicStreamFactory::~QuicStreamFactory()
> #12 0x00000201f445 net::HttpNetworkSession::~HttpNetworkSession()

This looks like something has been allocated by the pool but not released by the
time the test terminates. It's not obvious to me why. Jeremy?

ALos, I think you need to patch the epoll connection helper

[chromium-reviews, 2016-01-09 00:12:35]

Is the DCHECK mangled? I'd be surprised, but the message is strange.

Otherwise it seems like the ConnectionHelper is outliving something, though
I thought I addressed all of those when I merged the QuicBufferAllocator
change.
On Jan 8, 2016 6:52 PM, <rch@chromium.org> wrote:

> On 2016/01/08 23:05:45, Zhongyi Shi wrote:
>
>> Having issues for porting this cl:
>>
>
> A lot of tests crashed due to memory free. A sample stacktrace is as
>> follows:
>> [ RUN      ] Version/QuicNetworkTransactionTest.QuicProxyWithCert/4
>> [27986:27986:0108/145834:2225147252306:FATAL:quic_buffer_pool.h(327)]
>> Freeing
>> 0x3eaf6f761750 with 0 unfreed allocations.
>> #0 0x00000345917e base::debug::StackTrace::StackTrace()
>> #1 0x00000349128f logging::LogMessage::~LogMessage()
>> #2 0x0000010b304c net::QuicBufferPool<>::Region::~Region()
>> #3 0x000001cde455 std::array<>::~array()
>> #4 0x000001cdd8d1 net::QuicBufferPool<>::~QuicBufferPool()
>> #5 0x000001cdc623 net::QuicConnectionHelper::~QuicConnectionHelper()
>> #6 0x000001cdc659 net::QuicConnectionHelper::~QuicConnectionHelper()
>> #7 0x0000005fa46f std::default_delete<>::operator()()
>> #8 0x0000005fa431 base::internal::scoped_ptr_impl<>::reset()
>> #9 0x000001237869 base::internal::scoped_ptr_impl<>::~scoped_ptr_impl()
>> #10 0x000001237725 scoped_ptr<>::~scoped_ptr()
>> #11 0x0000020fda1d net::QuicStreamFactory::~QuicStreamFactory()
>> #12 0x00000201f445 net::HttpNetworkSession::~HttpNetworkSession()
>>
>
> This looks like something has been allocated by the pool but not released
> by the
> time the test terminates. It's not obvious to me why. Jeremy?
>
> ALos, I think you need to patch the epoll connection helper
>
> https://codereview.chromium.org/1577473002/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[chromium-reviews, 2016-01-09 14:16:14]

It's a bad DCHECK. I'll fix it internally shortly.

The problem is that the first Region never gets its memory released, so as
to avoid constantly mmaping and munmapping memory. That check violates that
assumption.

Why this doesn't happen internally is mind boggling.

On Fri, Jan 8, 2016 at 7:12 PM, Jeremy Dorfman <jdorfman@google.com> wrote:

> Is the DCHECK mangled? I'd be surprised, but the message is strange.
>
> Otherwise it seems like the ConnectionHelper is outliving something,
> though I thought I addressed all of those when I merged the
> QuicBufferAllocator change.
> On Jan 8, 2016 6:52 PM, <rch@chromium.org> wrote:
>
>> On 2016/01/08 23:05:45, Zhongyi Shi wrote:
>>
>>> Having issues for porting this cl:
>>>
>>
>> A lot of tests crashed due to memory free. A sample stacktrace is as
>>> follows:
>>> [ RUN      ] Version/QuicNetworkTransactionTest.QuicProxyWithCert/4
>>> [27986:27986:0108/145834:2225147252306:FATAL:quic_buffer_pool.h(327)]
>>> Freeing
>>> 0x3eaf6f761750 with 0 unfreed allocations.
>>> #0 0x00000345917e base::debug::StackTrace::StackTrace()
>>> #1 0x00000349128f logging::LogMessage::~LogMessage()
>>> #2 0x0000010b304c net::QuicBufferPool<>::Region::~Region()
>>> #3 0x000001cde455 std::array<>::~array()
>>> #4 0x000001cdd8d1 net::QuicBufferPool<>::~QuicBufferPool()
>>> #5 0x000001cdc623 net::QuicConnectionHelper::~QuicConnectionHelper()
>>> #6 0x000001cdc659 net::QuicConnectionHelper::~QuicConnectionHelper()
>>> #7 0x0000005fa46f std::default_delete<>::operator()()
>>> #8 0x0000005fa431 base::internal::scoped_ptr_impl<>::reset()
>>> #9 0x000001237869 base::internal::scoped_ptr_impl<>::~scoped_ptr_impl()
>>> #10 0x000001237725 scoped_ptr<>::~scoped_ptr()
>>> #11 0x0000020fda1d net::QuicStreamFactory::~QuicStreamFactory()
>>> #12 0x00000201f445 net::HttpNetworkSession::~HttpNetworkSession()
>>>
>>
>> This looks like something has been allocated by the pool but not released
>> by the
>> time the test terminates. It's not obvious to me why. Jeremy?
>>
>> ALos, I think you need to patch the epoll connection helper
>>
>> https://codereview.chromium.org/1577473002/
>>
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[chromium-reviews, 2016-01-09 14:19:41]

Ah ha! The original code was:
    LOG_IF_FIRST_N(DFATAL, 0 != next_free_, 10) << "Freeing " << this
                                                 << " with " << next_free_
                                                 << " unfreed allocations.";
The replacement code was:
QUIC_BUG << "Freeing " << this << " with " << next_free_ << " unfreed
allocations.";

The difference is that the replacement fires regardless of the state of
next_free_, while the original will only fire if next_free_ isn't 0.

Please wrap the QUIC_BUG in an if (0 != next_free_) {}.

-Jeremy

On Sat, Jan 9, 2016 at 9:16 AM, Jeremy Dorfman <jdorfman@google.com> wrote:

> It's a bad DCHECK. I'll fix it internally shortly.
>
> The problem is that the first Region never gets its memory released, so as
> to avoid constantly mmaping and munmapping memory. That check violates that
> assumption.
>
> Why this doesn't happen internally is mind boggling.
>
> On Fri, Jan 8, 2016 at 7:12 PM, Jeremy Dorfman <jdorfman@google.com>
> wrote:
>
>> Is the DCHECK mangled? I'd be surprised, but the message is strange.
>>
>> Otherwise it seems like the ConnectionHelper is outliving something,
>> though I thought I addressed all of those when I merged the
>> QuicBufferAllocator change.
>> On Jan 8, 2016 6:52 PM, <rch@chromium.org> wrote:
>>
>>> On 2016/01/08 23:05:45, Zhongyi Shi wrote:
>>>
>>>> Having issues for porting this cl:
>>>>
>>>
>>> A lot of tests crashed due to memory free. A sample stacktrace is as
>>>> follows:
>>>> [ RUN      ] Version/QuicNetworkTransactionTest.QuicProxyWithCert/4
>>>> [27986:27986:0108/145834:2225147252306:FATAL:quic_buffer_pool.h(327)]
>>>> Freeing
>>>> 0x3eaf6f761750 with 0 unfreed allocations.
>>>> #0 0x00000345917e base::debug::StackTrace::StackTrace()
>>>> #1 0x00000349128f logging::LogMessage::~LogMessage()
>>>> #2 0x0000010b304c net::QuicBufferPool<>::Region::~Region()
>>>> #3 0x000001cde455 std::array<>::~array()
>>>> #4 0x000001cdd8d1 net::QuicBufferPool<>::~QuicBufferPool()
>>>> #5 0x000001cdc623 net::QuicConnectionHelper::~QuicConnectionHelper()
>>>> #6 0x000001cdc659 net::QuicConnectionHelper::~QuicConnectionHelper()
>>>> #7 0x0000005fa46f std::default_delete<>::operator()()
>>>> #8 0x0000005fa431 base::internal::scoped_ptr_impl<>::reset()
>>>> #9 0x000001237869 base::internal::scoped_ptr_impl<>::~scoped_ptr_impl()
>>>> #10 0x000001237725 scoped_ptr<>::~scoped_ptr()
>>>> #11 0x0000020fda1d net::QuicStreamFactory::~QuicStreamFactory()
>>>> #12 0x00000201f445 net::HttpNetworkSession::~HttpNetworkSession()
>>>>
>>>
>>> This looks like something has been allocated by the pool but not
>>> released by the
>>> time the test terminates. It's not obvious to me why. Jeremy?
>>>
>>> ALos, I think you need to patch the epoll connection helper
>>>
>>> https://codereview.chromium.org/1577473002/
>>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Ryan Hamilton, 2016-01-09 17:19:26]

Thanks for the quic fix! Is there any chance that it *is* firing
internally, but that the QUIC_BUG macro (which is defined differently in
google3) is swallowing the failure?

On Sat, Jan 9, 2016 at 6:19 AM, Jeremy Dorfman <jdorfman@google.com> wrote:

> Ah ha! The original code was:
>     LOG_IF_FIRST_N(DFATAL, 0 != next_free_, 10) << "Freeing " << this
>                                                  << " with " << next_free_
>                                                  << " unfreed
> allocations.";
> The replacement code was:
> QUIC_BUG << "Freeing " << this << " with " << next_free_ << " unfreed
> allocations.";
>
> The difference is that the replacement fires regardless of the state of
> next_free_, while the original will only fire if next_free_ isn't 0.
>
> Please wrap the QUIC_BUG in an if (0 != next_free_) {}.
>
> -Jeremy
>
> On Sat, Jan 9, 2016 at 9:16 AM, Jeremy Dorfman <jdorfman@google.com>
> wrote:
>
>> It's a bad DCHECK. I'll fix it internally shortly.
>>
>> The problem is that the first Region never gets its memory released, so
>> as to avoid constantly mmaping and munmapping memory. That check violates
>> that assumption.
>>
>> Why this doesn't happen internally is mind boggling.
>>
>> On Fri, Jan 8, 2016 at 7:12 PM, Jeremy Dorfman <jdorfman@google.com>
>> wrote:
>>
>>> Is the DCHECK mangled? I'd be surprised, but the message is strange.
>>>
>>> Otherwise it seems like the ConnectionHelper is outliving something,
>>> though I thought I addressed all of those when I merged the
>>> QuicBufferAllocator change.
>>> On Jan 8, 2016 6:52 PM, <rch@chromium.org> wrote:
>>>
>>>> On 2016/01/08 23:05:45, Zhongyi Shi wrote:
>>>>
>>>>> Having issues for porting this cl:
>>>>>
>>>>
>>>> A lot of tests crashed due to memory free. A sample stacktrace is as
>>>>> follows:
>>>>> [ RUN      ] Version/QuicNetworkTransactionTest.QuicProxyWithCert/4
>>>>> [27986:27986:0108/145834:2225147252306:FATAL:quic_buffer_pool.h(327)]
>>>>> Freeing
>>>>> 0x3eaf6f761750 with 0 unfreed allocations.
>>>>> #0 0x00000345917e base::debug::StackTrace::StackTrace()
>>>>> #1 0x00000349128f logging::LogMessage::~LogMessage()
>>>>> #2 0x0000010b304c net::QuicBufferPool<>::Region::~Region()
>>>>> #3 0x000001cde455 std::array<>::~array()
>>>>> #4 0x000001cdd8d1 net::QuicBufferPool<>::~QuicBufferPool()
>>>>> #5 0x000001cdc623 net::QuicConnectionHelper::~QuicConnectionHelper()
>>>>> #6 0x000001cdc659 net::QuicConnectionHelper::~QuicConnectionHelper()
>>>>> #7 0x0000005fa46f std::default_delete<>::operator()()
>>>>> #8 0x0000005fa431 base::internal::scoped_ptr_impl<>::reset()
>>>>> #9 0x000001237869 base::internal::scoped_ptr_impl<>::~scoped_ptr_impl()
>>>>> #10 0x000001237725 scoped_ptr<>::~scoped_ptr()
>>>>> #11 0x0000020fda1d net::QuicStreamFactory::~QuicStreamFactory()
>>>>> #12 0x00000201f445 net::HttpNetworkSession::~HttpNetworkSession()
>>>>>
>>>>
>>>> This looks like something has been allocated by the pool but not
>>>> released by the
>>>> time the test terminates. It's not obvious to me why. Jeremy?
>>>>
>>>> ALos, I think you need to patch the epoll connection helper
>>>>
>>>> https://codereview.chromium.org/1577473002/
>>>>
>>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[chromium-reviews, 2016-01-09 19:54:46]

No, this was introduced in the merge. QUIC_BUG is not equivalent to
LOG_IF_FIRST_N. I've confirmed this isn't firing internally.
On Jan 9, 2016 12:19 PM, "Ryan Hamilton" <rch@chromium.org> wrote:

> Thanks for the quic fix! Is there any chance that it *is* firing
> internally, but that the QUIC_BUG macro (which is defined differently in
> google3) is swallowing the failure?
>
> On Sat, Jan 9, 2016 at 6:19 AM, Jeremy Dorfman <jdorfman@google.com>
> wrote:
>
>> Ah ha! The original code was:
>>     LOG_IF_FIRST_N(DFATAL, 0 != next_free_, 10) << "Freeing " << this
>>                                                  << " with " << next_free_
>>                                                  << " unfreed
>> allocations.";
>> The replacement code was:
>> QUIC_BUG << "Freeing " << this << " with " << next_free_ << " unfreed
>> allocations.";
>>
>> The difference is that the replacement fires regardless of the state of
>> next_free_, while the original will only fire if next_free_ isn't 0.
>>
>> Please wrap the QUIC_BUG in an if (0 != next_free_) {}.
>>
>> -Jeremy
>>
>> On Sat, Jan 9, 2016 at 9:16 AM, Jeremy Dorfman <jdorfman@google.com>
>> wrote:
>>
>>> It's a bad DCHECK. I'll fix it internally shortly.
>>>
>>> The problem is that the first Region never gets its memory released, so
>>> as to avoid constantly mmaping and munmapping memory. That check violates
>>> that assumption.
>>>
>>> Why this doesn't happen internally is mind boggling.
>>>
>>> On Fri, Jan 8, 2016 at 7:12 PM, Jeremy Dorfman <jdorfman@google.com>
>>> wrote:
>>>
>>>> Is the DCHECK mangled? I'd be surprised, but the message is strange.
>>>>
>>>> Otherwise it seems like the ConnectionHelper is outliving something,
>>>> though I thought I addressed all of those when I merged the
>>>> QuicBufferAllocator change.
>>>> On Jan 8, 2016 6:52 PM, <rch@chromium.org> wrote:
>>>>
>>>>> On 2016/01/08 23:05:45, Zhongyi Shi wrote:
>>>>>
>>>>>> Having issues for porting this cl:
>>>>>>
>>>>>
>>>>> A lot of tests crashed due to memory free. A sample stacktrace is as
>>>>>> follows:
>>>>>> [ RUN      ] Version/QuicNetworkTransactionTest.QuicProxyWithCert/4
>>>>>> [27986:27986:0108/145834:2225147252306:FATAL:quic_buffer_pool.h(327)]
>>>>>> Freeing
>>>>>> 0x3eaf6f761750 with 0 unfreed allocations.
>>>>>> #0 0x00000345917e base::debug::StackTrace::StackTrace()
>>>>>> #1 0x00000349128f logging::LogMessage::~LogMessage()
>>>>>> #2 0x0000010b304c net::QuicBufferPool<>::Region::~Region()
>>>>>> #3 0x000001cde455 std::array<>::~array()
>>>>>> #4 0x000001cdd8d1 net::QuicBufferPool<>::~QuicBufferPool()
>>>>>> #5 0x000001cdc623 net::QuicConnectionHelper::~QuicConnectionHelper()
>>>>>> #6 0x000001cdc659 net::QuicConnectionHelper::~QuicConnectionHelper()
>>>>>> #7 0x0000005fa46f std::default_delete<>::operator()()
>>>>>> #8 0x0000005fa431 base::internal::scoped_ptr_impl<>::reset()
>>>>>> #9 0x000001237869
>>>>>> base::internal::scoped_ptr_impl<>::~scoped_ptr_impl()
>>>>>> #10 0x000001237725 scoped_ptr<>::~scoped_ptr()
>>>>>> #11 0x0000020fda1d net::QuicStreamFactory::~QuicStreamFactory()
>>>>>> #12 0x00000201f445 net::HttpNetworkSession::~HttpNetworkSession()
>>>>>>
>>>>>
>>>>> This looks like something has been allocated by the pool but not
>>>>> released by the
>>>>> time the test terminates. It's not obvious to me why. Jeremy?
>>>>>
>>>>> ALos, I think you need to patch the epoll connection helper
>>>>>
>>>>> https://codereview.chromium.org/1577473002/
>>>>>
>>>>
>>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Zhongyi Shi, 2016-01-12 00:04:40]

The CQ bit was checked by zhongyi@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-01-12 00:06:53]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1577473002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1577473002/20001

[commit-bot: I haz the power, 2016-01-12 00:06:53]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-01-12 00:06:54]

Dry run: No L-G-T-M from a valid reviewer yet. Only full committers are
accepted.
Even if an L-G-T-M may have been provided, it was from a non-committer,
_not_ a full super star committer.
See http://www.chromium.org/getting-involved/become-a-committer
Note that this has nothing to do with OWNERS files.

[Zhongyi Shi, 2016-01-12 03:25:04]

Seems like #include <sys/mman.h> is unix only and not available from windows.

[chromium-reviews, 2016-01-12 11:57:52]

I can think of 3 options:
1. Switch mmap to use VirtualAllocEx with MEM_RESERVE|MEM_COMMIT, and
optionally do the win32 hugepage dance (requires some nondefault
privileges).
2. Switch out mmap/munmap with aligned_malloc/aligned_free for Chromium
only.
3. Don't use QuicBufferPool in Chromium.

Thoughts?
On Jan 11, 2016 10:25 PM, <zhongyi@chromium.org> wrote:

> Seems like #include <sys/mman.h> is unix only and not available from
> windows.
>
> https://codereview.chromium.org/1577473002/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Ryan Hamilton, 2016-01-15 00:42:49]

assuming this looks good to jeremy, lgtm

[Jeremy Dorfman, 2016-01-15 01:46:53]

On 2016/01/15 00:42:49, Ryan Hamilton wrote:
> assuming this looks good to jeremy, lgtm

There are some signed/unsigned comparison issues, and it's a bit redundant to
have MmapPreserveErrno at all if we're always going to use only AlignedAlloc.
Otherwise, LG.

[Zhongyi Shi, 2016-01-19 18:44:21]

Patchset #8 (id:140001) has been deleted

[Zhongyi Shi, 2016-01-19 19:36:03]

Patchset #9 (id:180001) has been deleted