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"
