01:00 <bbot2> Started: http://buildbot.pypy.org/builders/own-linux-x86-64/builds/8131 [py3.6]

01:00 <bbot2> Started: http://buildbot.pypy.org/builders/own-linux-aarch64/builds/458 [py3.6]

01:00 <bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-aarch64/builds/469 [py3.6]

01:00 <bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-macosx-x86-64/builds/5045 [py3.6]

01:00 <bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/6945 [py3.6]

01:00 <bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/5281 [py3.6]

01:56 <bbot2> Success: http://buildbot.pypy.org/builders/own-linux-x86-64/builds/8131 [py3.6]

02:18 <bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/6945 [py3.6]

03:10 <bbot2> Failure: http://buildbot.pypy.org/builders/own-linux-aarch64/builds/458 [py3.6]

03:35 <bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/5281 [py3.6]

03:43 <bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-macosx-x86-64/builds/5045 [py3.6]

06:04 <bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-aarch64/builds/469 [py3.6]

11:57 <phlebas> when i jit.promote a W_Object, it turns into a guard. what does the backend do here? is the object moved to the old space and there's a literal cmp and jne for the pointer?

11:57 <cfbolz> phlebas: yes, I think so

11:58 <cfbolz> promote will keep the object alive

11:58 <cfbolz> why?

11:59 <phlebas> i'm wondering about the promotions on modules if their dict doesn't change. that prevents the module from being collected then? or does the GC ignore pointers in the generated machine code?

11:59 <cfbolz> yes, it prevents the modules from being collected

11:59 <cfbolz> (unless the trace is collected)

12:04 <phlebas> ok, so i guess when i would try construct a synthetic case where a module gets promoted and then gc'd, the trace will be collected eventually because it's not used anymore? or would i have to make sure it gets executed again with the guard failing often enough?

12:04 <phlebas> s/gc'd/becomes unreachable by user code/

12:09 <cfbolz> exactly

12:09 <cfbolz> phlebas: if the code of the module is never executed, the involved traces get collected

12:09 <cfbolz> and then the module too

12:09 <phlebas> ah, ok

12:10 <cfbolz> phlebas: basically traces have some kind of "age", and if they aren't executed in 'a while' (however time is measured here) they get collected

12:12 <phlebas> makes sense, you wouldn't want to keep traces from the startup code around forever

12:12 <cfbolz> exactly

12:12 <cfbolz> how does graal handle that?

12:21 <phlebas> it doesn't, there's no jit.promote, right? it's all caching things in the AST and telling the compiler "these rarely change". but that's a proper field in the AST, which is not collected just because it doesn't run, as long as the function that it belongs to lives. so there's a potential memory leak when we do what pypy does

12:22 <cfbolz> phlebas: who holds a reference to the AST?

12:22 <cfbolz> shouldn't that be ok, because only the module does?

12:43 <phlebas> hm, true, that would be ok. the ast is held alive by the source object also, however, which is a truffle thing to share ASTs across multiple language contexts in the same VM

12:49 <antocuni> phlebas, cfbolz: IIRC, in pypy the "age" of traces follow some kind of exponential decay rule, FWIW

15:57 <antocuni> is there any way to speed up the linking process of a translation? I am trying to modify C files by hand and it's by far the most time consuming step

15:58 <tumbleweed> the gold linker is faster, but dunno if it works on pypy

15:59 <antocuni> I'm not sure I want to try exotic stuff :). I was hoping there is some magic flags which turns off some optimizations, or things like that

16:02 <mattip> yeah it is painful to link. Maybe we could improve our c generation with an eye to linking faster

16:02 <antocuni> how?

16:02 <mattip> like identify functions that are only called once and inline them

16:03 <antocuni> or maybe mark them as static

16:03 <mattip> do we have a static decorator?

16:04 <antocuni> no, and I don't even know how it would work. Would it forbid calling the function from outside the python module and/or subpackage?

16:05 <antocuni> I was more thinking of automatically detecting which functions are called only from within the same .c file

16:05 <antocuni> probably there are a lot of them, because c files are split by directory

16:06 <mattip> yeah, probably a dumb idea

16:07 <mattip> and separate compilation of the modules is not going to happen

16:07 <antocuni> well, as a general idea, it would be nice to have a better way to declare which functions are "exported" by a module/package, possibly with their annotation. It would be a step forward towards separate compilation

16:08 <antocuni> but yes, I don't see separate compilation happening any time soon

16:19 <mattip> @public? @exported? @public_api ?

16:21 <antocuni> ideally, it would be nice to use function annotations, but for this we first need rpython3 :)

16:22 <antocuni> (or invent a hack which let us use function annotations on python2 code as well)

16:40 <mattip> ronan did some nice refactoring of eval for rpython, but there is still a ways to go before

16:40 <mattip> python3 pytest.py pypy/doc

16:40 <mattip> works

16:43 <antocuni> what do you mean by "refactoring of eval"?

17:09 <mattip> commit c067c8c93177 "Modernize exec syntax in rpython/"

17:10 <mattip> sorry, exec not eval

18:20 <antocuni> aaah ok

18:20 <antocuni> yes, although the real problems for rpython3 are much deeper of course

18:23 <tumbleweed> gotta start somewhere :)

19:15 <Dejan> so there is plan for rpython3

19:15 <Dejan> good to know :)

19:22 <mattip> no, there is no plan, only wisps of dreams