Date: Fri, 09 Sep 2016 14:06:21 +0300 From: Arto Pekkanen <isoa@kapsi.fi> To: clutton <clutton@zoho.com> Cc: freebsd-chromium <freebsd-chromium@freebsd.org> Subject: Re: 52.0.2743.82 (64-bit) to go, Aw snap is still there Message-ID: <732bbbfa1ca6903e0f76e4f98a955a28@kapsi.fi> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?732bbbfa1ca6903e0f76e4f98a955a28>