Hi Marty,
I have recently looked into the branch again. I am not sure if there were any bugs when we last left it. The main issue I currently see with the code (and that is my fault) is that it allocates a frame for efun calls. This does not happen in pike currently and I suppose we want to keep it that way. The current API in the new branch unfortunately requires this for keeping the information about the frame type.
I have recently tried to rebase that branch onto current pike 8.1 in order to attempt another refactoring to address that particular problem. However, that did not go very well in the end because I encountered huge merge conflicts and gave up. I am a bit undecided at the moment how we should go forward with this.
My current feeling is that the new API is broken and should be replaced by something which:
1) optimizes lookup and frame allocation for map/filter/automap 2) does not allocate a frame for efun calls 3) allows easy integration of frame caching ... n) continuations?
I have written down some notes last time I looked at this, but its all very early stage right now.
On the other hand, maybe what we want to achieve for 8.1 is only the first part. Maybe we can come up with some kind of intermediate version which does that?
Arne
On Mon, 9 Jan 2017, Martin Karlgren wrote:
Hi Arne,
I'm curious about what you think it would take to merge the faster_calls branch to 8.1? Do you know about any outstanding issues or is it mostly about rebasing it to 8.1 head and running the testsuite?
Thanks, Marty
24 apr. 2016 kl. 16:10 skrev Arne Goedeke el@laramies.com:
This fatal is actually also happening in usual pike 8.1, so i guess its unrelated to the new branch. The fatal happens during cleanup on exit, should that not make sure that things are cleaned up in the correct order? Or should the check be disabled on the final gc run when all objects are freed?
arne
On 04/23/16 16:10, Arne Goedeke wrote: I have been able to fix a couple of bugs in the branch by now. There are some left, which I could use some help to understand why they occur. One is triggered by the DHT.test in the bittorrent library. When running that test in the 'faster_calls' branch with debug enabled, the following fatal occurs:
/home/el/code/rw/pike/src/gc.c:3864: GC fatal: GC destructed parent prematurely. **Block: 0x7f0d52594180 Type: object Refs: 5 **Got gc marker at 0x753e010: flags=0x20001e refs=4 weak=2 xrefs=0 saved=4 frame=0x61b1d80 [data=0x7f0d52594180 rf_flags=0x95 prev=(nil) next=0x61b1d48 cycle_id=0x61b1d80 cycle_piece=0xffffffffffffffff link_top/last_cycle_piece=0xffffffffffffffff] **Parent identifier: 20 **Program id: 66099 **Object variables: ** rtt: mixed name: state off: 56 value: 1 ** rtt: mixed name: ping_fails off: 72 value: 0 ** rtt: mixed name: last_ping off: 88 value: 1461419197 ** rtt: mapping name: pings_inflight off: 104 value: mapping of size 0 ** rtt: mixed name: last_response off: 112 value: 1461419362 ** rtt: mixed name: check_node_callout off: 128 value: array of size 1 ** === In inherit "Node", program 66100: ** rtt: string name: node_id off: 16 value: "O\366\355\207%n\277j4fI\323\231;\332|9Vu\30" ** rtt: string name: address off: 24 value: "127.0.0.1" ** rtt: string name: token off: 32 value: "\370\373S\252""5\336\322\25\312[\205\201qR3h]\235z\311" ** rtt: mixed name: port off: 40 value: 7010 **Describing program 0x20fd070 of object: **Got gc marker at 0x76c8cb0: flags=0x0000e refs=15106 weak=0 xrefs=0 saved=15106 frame=(nil) **Program id: 66099, flags: 308f, parent id: 66097 **Location: /home/el/local/pike/8.1.4/lib/modules/Protocols.pmod/Bittorrent.pmod/DHT.pike:601 **Object got a parent.
Pike was in GC stage 400 when this fatal occurred. Backtrace at time of fatal:
Subprocess died of signal SIGABRT.
So apparently the parent object was destructed before its child. Does anyone have any ideas what parts of the function call part in interpret.c might be incorrect? Is the PARENT_CLONE case wrong?
Thanks
Arne