From owner-freebsd-chromium@freebsd.org Fri Sep 9 11:06:27 2016 Return-Path: Delivered-To: freebsd-chromium@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FE3ABD4F72 for ; Fri, 9 Sep 2016 11:06:27 +0000 (UTC) (envelope-from isoa@kapsi.fi) Received: from mail.kapsi.fi (mx1.kapsi.fi [IPv6:2001:1bc8:1004::1:25]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4228B938 for ; Fri, 9 Sep 2016 11:06:27 +0000 (UTC) (envelope-from isoa@kapsi.fi) Received: from karviainen.kapsi.fi ([217.30.184.182] helo=roundcube.kapsi.fi) by mail.kapsi.fi with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1biJdV-0000Xj-Jc; Fri, 09 Sep 2016 14:06:22 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 09 Sep 2016 14:06:21 +0300 From: Arto Pekkanen To: clutton Cc: freebsd-chromium In-Reply-To: <1472985750.17294.22.camel@zoho.com> References: <1471486169.7533.8.camel@zoho.com> <1472667320.8146.46.camel@zoho.com> <1d42dcb1faf8cbe4fbf24066a4163134@kapsi.fi> <1472985750.17294.22.camel@zoho.com> Message-ID: <732bbbfa1ca6903e0f76e4f98a955a28@kapsi.fi> X-Sender: isoa@kapsi.fi User-Agent: RoundCube Webmail/0.9.4 X-SA-Exim-Connect-IP: 217.30.184.182 X-SA-Exim-Mail-From: isoa@kapsi.fi X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail X-Spam-Level: X-Spam-Status: No, score=-4.6 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD autolearn=ham version=3.3.2 Subject: Re: 52.0.2743.82 (64-bit) to go, Aw snap is still there X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mail.kapsi.fi) X-BeenThere: freebsd-chromium@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: FreeBSD-specific Chromium issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 11:06:27 -0000 Cool! Thanks for the info. Now I know where we're going with the project. I suppose we will see later how the collaboration with upstream goes. Awesome work with GN/ninja btw, that will help a lot in the future! clutton kirjoitti 04.09.2016 13:42: > On Sun, 2016-09-04 at 02:30 +0300, Arto Pekkanen wrote: >> So I was right from the very start: the Chromium codebase assumes  >> certain behaviour from the memory allocation API of the host system, >> and  >> if this behavour is not in line with Linux (and Android), then >> problems  >> are to be expected. Yeah. Yet another fine example of how Open Source >> is  >> becoming synonymous with "Designed for Linux". >> >> Is there any hope to get these changes propagated upstream to >> Chromium  >> developers? >> >> It would be really nice to have upstream collaboration, because if >> the  >> upstream yet again changes things ever so slightly, things will  >> mysteriously break. > > No, you wasn't right about the memory. I just wrote - base allocator > works fine. Their home-brew assembler snippets work fine. I haven't > checked blink allocator as thoroughly as base, may be it's there > something not right. Do not assume that chromium is bug-free also. > Some shit may fire with conditions met. > > For now I have GN ninja fully working (I believe I'll commit today), I > doubt that google would take it upstream, such a mess to add another > architecture. Nevertheless - I'm using macros is_bsd, with assumption > that code would use OS_BSD, and with some division > OS_OPENBSD/OS_FREEBSD further in C/C++ code, so it's more clean and has > more chances to be accepted. But may no mistake - they invest a lot of > resources to make this chrome work according to a plan, I don't think > that they would add another OS. Unless there are a lot of people > interested. > > About Linuxism, - they divide code very simple, if you don't like the > functionality, you can rewrite it for your OS... The thing is - we use > a lot of code written for Linux. > > >> clutton kirjoitti 31.08.2016 21:15: >> > >> > On Thu, 2016-08-18 at 05:09 +0300, clutton wrote: >> > > >> > > I've just fixed the Aw, snap. I believe so. >> > Ok, time to admit the defeat. I haven't fixed the issue in time, >> > and I >> > planned to do so till the summer is there. Being to much arrogant I >> > started just before the end of time. I still can't believe I >> > haven't >> > fixed this in time. >> > >> > I'll work on this, but not so intensively, now I just can't left >> > it. >> > I learned about the codebase so much. And all those small >> > improvements >> > shouldn't be wasted anyway (I haven't posted any because they worth >> > nothing without fixing the bug). I'll do it more slowly and >> > considerably now. >> > >> > Number 1 issue is to bring new gn ninja generation system, every >> > documentation assumes that you use gn, in future they will remove >> > gyp >> > generator. It would be much easier to work then. >> > Number 2 is probably to clean the mess in our pathes. >> > >> > Some thoughts for maintainers/developers: >> > >> > Don't try debugging if you don't have enough RAM, I distributed the >> > compilation to distcc, but RAM was an issue, even with another ssd >> > attached as a swap it was tooooo slow to work with debugger, I did >> > a >> > lot of tricks to make it possible though, And have a lot of >> > frustrations when those tricks mangle the code. I wish I could just >> > put >> > that monster in RAM press bt and don't wait 5 minutes till it's >> > done. >> > >> > Memory allocation in base works fine, I might missed something but >> > debugging bit after bit was fine, then I finally did stubs, then I >> > finally found that new shim allocator have those stubs already, >> > some >> > fixes would be needed though, for now I used this: >> > allocator_shim_default_dispatch_to_libc.cc >> > extern "C" { >> > void* __malloc(size_t size); >> > void* __calloc(size_t n, size_t size); >> > void* __realloc(void* address, size_t size); >> > void* __memalign(size_t alignment, size_t size) { >> >   void *ret; >> >   if (__posix_memalign(&ret, alignment, size) != 0) { >> >     return nullptr; >> >   } else { >> >     return ret; >> >   } >> > } >> > int  __posix_memalign(void **ptr, size_t alignment, size_t size); >> > void __free(void* ptr); >> > }  // extern "C" >> > >> > But they assume linux and android, and they implement >> > posix_memalign >> > through memalign, I did the opposite. For now I have that >> > unnecessary >> > chain. It works but it could work faster without chain. >> > >> > I haven't debugged heavily blink memory allocator, which I should >> > have >> > done instead of base allocator... There are some approaches to make >> > it >> > not to crush, but they are just hardcode patching, not fixing. And >> > some >> > patches I thought work just delaying the freezing. >> > >> > Next, chromium team patch libraries, those in third_party >> > directory, I >> > debugged some of them, seems fine. No difference in work comparing >> > to >> > our. But that is probably is something to look at more. Ninja >> > sucks, >> > once I put the most recent re2 library by mistake and ninja >> > compiled it >> > without hesitation. Then I had coredumps on that library. >> > >> > >> > Ok, probably all, because writing everything would be to much for >> > non >> > prepared reader. Better send patches. "Talk is cheap. Show me the >> > code" -- Arto Pekkanen