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 <[email protected]>:
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
