DAVEM TPF Grant#2 May 2019 report

The main thing I have been doing over the last month is to make the
optree-walking functions in op.c  non-recursive and/or non-leaky.

In auto-generated code, such as

    $a[0][0][0][0]..

and things involving arbitrary-deep nesting of braces and parentheses,
it's easy during compilation to create a deep optree. Many functions in
op.c walk those trees using recursion, which can blow the stack and cause
a crash. This is especially noticeable under threads, where each thread by
default only gets a relatively small stack.

Some functions were modified to malloc() a buffer to keep track, but that
could leak if the compiler croaked during tree traversal.

SUMMARY:
      1:00 fix 32-bit builds
     26:55 make optree functions in op.c non-recursive and/or non-leaky.
    ------
     27:55 TOTAL (HH::MM)

 293.7 weeks
3338.1 total hours
  11.4 average hours per week

There are 128 hours left on the grant

-- 
Diplomacy is telling someone to go to hell in such a way that they'll
look forward to the trip
0
davem
6/3/2019 10:22:12 AM
perl.perl5.porters 47708 articles. 1 followers. Follow

2 Replies
41 Views

Similar Articles

[PageSpeed] 24

--Sig_/FqI0/AaZgBK2wW5wI=xyJ6Y
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Nice work, thanks Dave! +1 from me.


On 2019-06-03, at 11:22:12 +0100, Dave Mitchell wrote:

> The main thing I have been doing over the last month is to make the
> optree-walking functions in op.c  non-recursive and/or non-leaky.
>=20
> In auto-generated code, such as
>=20
>     $a[0][0][0][0]..
>=20
> and things involving arbitrary-deep nesting of braces and parentheses,
> it's easy during compilation to create a deep optree. Many functions in
> op.c walk those trees using recursion, which can blow the stack and cause
> a crash. This is especially noticeable under threads, where each thread by
> default only gets a relatively small stack.
>=20
> Some functions were modified to malloc() a buffer to keep track, but that
> could leak if the compiler croaked during tree traversal.
>=20
> SUMMARY:
>       1:00 fix 32-bit builds
>      26:55 make optree functions in op.c non-recursive and/or non-leaky. =
=20
>     ------
>      27:55 TOTAL (HH::MM) =20
>=20
>  293.7 weeks
> 3338.1 total hours
>   11.4 average hours per week
>=20
> There are 128 hours left on the grant
>=20
> --=20
> Diplomacy is telling someone to go to hell in such a way that they'll
> look forward to the trip


--=20
I THINK THEY SHOULD CONTINUE the policy of not giving a Nobel Prize for
paneling.
		-- Jack Handley, The New Mexican, 1988.

--Sig_/FqI0/AaZgBK2wW5wI=xyJ6Y
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQSMNgHejxbagKkr5E35YevWJoC7RgUCXPfHUgAKCRD5YevWJoC7
RrEoAJ9ACcukKvvtKbU/Z517B8wRaHzN2gCeItgdpd16p0LwVuCAQfcOT7MYXb0=
=wvI0
-----END PGP SIGNATURE-----

--Sig_/FqI0/AaZgBK2wW5wI=xyJ6Y--
0
mhx
6/5/2019 1:44:50 PM
+1!


Thanks, Dave!


On 6/3/19 1:22 PM, Dave Mitchell wrote:
> The main thing I have been doing over the last month is to make the
> optree-walking functions in op.c  non-recursive and/or non-leaky.
>
> In auto-generated code, such as
>
>     $a[0][0][0][0]..
>
> and things involving arbitrary-deep nesting of braces and parentheses,
> it's easy during compilation to create a deep optree. Many functions in
> op.c walk those trees using recursion, which can blow the stack and cause
> a crash. This is especially noticeable under threads, where each thread by
> default only gets a relatively small stack.
>
> Some functions were modified to malloc() a buffer to keep track, but that
> could leak if the compiler croaked during tree traversal.
>
> SUMMARY:
>       1:00 fix 32-bit builds
>      26:55 make optree functions in op.c non-recursive and/or non-leaky.
>     ------
>      27:55 TOTAL (HH::MM)
>
>  293.7 weeks
> 3338.1 total hours
>   11.4 average hours per week
>
> There are 128 hours left on the grant
>
0
xsawyerx
6/5/2019 5:51:24 PM
Reply: