Date: Sun, 04 Sep 2016 13:42:30 +0300 From: clutton <clutton@zoho.com> To: Arto Pekkanen <isoa@kapsi.fi> Cc: freebsd-chromium <freebsd-chromium@freebsd.org> Subject: Re: 52.0.2743.82 (64-bit) to go, Aw snap is still there Message-ID: <1472985750.17294.22.camel@zoho.com> In-Reply-To: <1d42dcb1faf8cbe4fbf24066a4163134@kapsi.fi> References: <1471486169.7533.8.camel@zoho.com> <1472667320.8146.46.camel@zoho.com> <1d42dcb1faf8cbe4fbf24066a4163134@kapsi.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-LTnLIU3AG712P9+Uj4hC
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Sun, 2016-09-04 at 02:30 +0300, Arto Pekkanen wrote:
> So I was right from the very start: the Chromium codebase assumes=C2=A0
> certain behaviour from the memory allocation API of the host system,
> and=C2=A0
> if this behavour is not in line with Linux (and Android), then
> problems=C2=A0
> are to be expected. Yeah. Yet another fine example of how Open Source
> is=C2=A0
> becoming synonymous with "Designed for Linux".
>=20
> Is there any hope to get these changes propagated upstream to
> Chromium=C2=A0
> developers?
>=20
> It would be really nice to have upstream collaboration, because if
> the=C2=A0
> upstream yet again changes things ever so slightly, things will=C2=A0
> 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=C2=A0is_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:
> >=20
> > On Thu, 2016-08-18 at 05:09 +0300, clutton wrote:
> > >=20
> > > 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.
> >=20
> > 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.
> >=20
> > 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.
> >=20
> > Some thoughts for maintainers/developers:
> >=20
> > 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.
> >=20
> > 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) {
> > =C2=A0 void *ret;
> > =C2=A0 if (__posix_memalign(&ret, alignment, size) !=3D 0) {
> > =C2=A0=C2=A0=C2=A0=C2=A0return nullptr;
> > =C2=A0 } else {
> > =C2=A0=C2=A0=C2=A0=C2=A0return ret;
> > =C2=A0 }
> > }
> > int=C2=A0=C2=A0__posix_memalign(void **ptr, size_t alignment, size_t si=
ze);
> > void __free(void* ptr);
> > }=C2=A0=C2=A0// extern "C"
> >=20
> > 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.
> >=20
> > 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.
> >=20
> > 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.
> >=20
> >=20
> > Ok, probably all, because writing everything would be to much for
> > non
> > prepared reader. Better send patches. "Talk is cheap. Show me the
> > code"
--=-LTnLIU3AG712P9+Uj4hC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJXy/qWAAoJEH2wP42yyP6QunIQAIW9W6L8TrSLdtf74bFOaDzO
ixMsmtAzvJZWFkhhMXDB6+1CC5unxqMDI9kcFNm7oOxSTtvnbDkGmGBQ6fOkCpLI
aqsOLJ7PmgeAaiYc3cnJ1OM5RC8q6r/gmiZkIh5rJvQCmebI6bSbqFVtVXm1EpR/
3gbuwOArJR2wNcLqle28PI3vUjp+s0cU1HPb8J1uIIPf/g3oETau5utk4FU3cDlo
6TeQSlK2ztzEctDkgSAJip65YfqqYNMwMwklP9gVV9E/S0uC0ozPfcSE19y3IcXc
kdRoi5P0DMeDiPZrSa0AD3HQeTpqFeR0LCxlbBWTkOOlZo80fK3/nvyScbuwZwZU
/d4qDYVRQpCmbr/CMKhD5LWD9MI9dQDkYSKkpRRcjq5g35utJae8y85dlTGqrkYL
hiOo64CotCr2g4jxwgRnfW1eAOFeZlpwESXikOC09eZPRpUnr7APWflAS36ifI0e
0r2hRhQ/qqo3VU8Uxyw67Kmg/bbbvv5GnK5zYWGs75CdvGPSC5Y8iVoxfD7fwq2M
tiAMuScpD3ffVvGcemzAkV7pwfX9lmw+/K9Dia8TjD0yX8QoxV9sAfgWycSVA4Uu
RJx6WQVro+jEsgUT4vnJtELb0PW0Z6dVfREuwGn6D/ectlAS/h1ngw2DxTJ4r0Sk
TAs+hS9I1nZUgLilYM1X
=WoMj
-----END PGP SIGNATURE-----
--=-LTnLIU3AG712P9+Uj4hC--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1472985750.17294.22.camel>