00:02 Ben_Goldberg joined 00:04 arnsholt_ joined 00:21 dalek joined 01:06 cognominal__ joined 01:08 moritz joined 01:09 rurban1 joined 01:10 rurban2 joined 02:05 rurban1 joined 03:16 FROGGS joined 04:20 ssutch joined 05:15 FROGGS joined 05:26 FROGGS joined, ssutch joined 06:13 FROGGS joined 06:50 FROGGS joined 07:37 lizmat joined 07:45 woolfy left 07:48 FROGGS joined 09:41 ssutch joined
FROGGS FYI: 09:56
stage parse rakudo@parrot: 197.062s
stage parse rakudo@moar: 359.375s
stage parse rakudo@optimized moar: 197.516s
that is on a Windows 7 x64
(since I am unable to use an optimized moar on linux for rakudo atm)
nwc10 FROGGS: what goes wrong with an optimised Moar on Linux? 10:03
and that's 197s both for optimised parrot and optimised Moar on Win7 x86_64? ie they are currently the same speed? 10:04
FROGGS nwc10: yes, optimized parrot
nwc10: there seems to be a gc bug that is showing up 10:05
I tried to hunt it down, but without any luck 10:08
10:15 lizmat joined
jnthn FROGGS: You're saying that optimized Moar does stage parse in same time as optimized Parrot? When I've still got some obvious performance bugs showing up in the profile? Nice :) 10:16
And that's *before* doing the nice type specialization stuff :) 10:17
FROGGS yes, I actually looked twice to confirm that it bailed out afterwards about something.moarvm :o)
jnthn: any advice how I should try to hunt down the gc bug? 10:18
jnthn FROGGS: Look down the stack trace and see what we had just done before calling process_worklist 10:23
That is, did we just push temp roots and are working on thsoe? Or something else? etc.
That *may* help
You can also set a breakpoint on the fromspace check panic and see what kind of thing it is 10:24
FROGGS k, thanks
jnthn back to teachign & 10:25
10:40 tgt joined
nwc10 another really intensive way to nail these sort of things is to rebuild each C object file (in this case of moarvm) in turn with optimisaiton, and see which one causes the GC bug to appear 11:15
and then spit it apart, and build function by function with optimisation
FROGGS hmmm, that is a nice idea 11:16
nwc10 but that's really only the fallback when "try to be smart" hasn't worked
and it may be that more than one needs to be built optimised
FROGGS true
nwc10 I see this (hope the paste isn't messed up): 11:30
Stage start : 0.000
Stage parse : 235.331Stage syntaxcheck: 0.000Stage ast : 0.000Bytecode validation error at offset 254, instruction 35:extension op 'p6trialbind' not registered
oh, yes, so it is 11:31
that's with gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3)
at (I think) -O3
11:39 cognominal__ joined 12:51 benabik joined
FROGGS gah, I can't even set breakpoints using the optimized build :o( 13:01
arnsholt Have you checked that it's built with debugging info? 13:02
-g should be in the CFLAGS 13:03
FROGGS ahh!
arnsholt: thanks! I'll try
arnsholt++ 13:04
\o/
p *item 13:07
$6 = {owner = 0, flags = 0, size = 56, forwarder = 0x0, sc = 0x0}
arnsholt If you're using GCC, I recommend using -g3 13:09
FROGGS k, what does this do?
arnsholt Then macros are stored in the debugging info
FROGGS k
arnsholt So that GDB understands what macros mean 13:10
In macroheavy code, it's really nice
FROGGS yeah, absolutely
but... what should I do now? I had thought that this item keeps a pointer to an MVMObject or so... 13:11
arnsholt That's harder =) 13:15
But it looks like it's not fully initialised, given the owner and sc being NULL
FROGGS "ownder is 0 if there is no held mutex" 13:16
owner*
/* Pointer to the serialization context this collectable lives in, if any. */
MVMSerializationContext *sc;
so, seems valid
can I dump these 56 bytes somehow? 13:17
ohh, I think I know 13:18
hmmm, not very helpful 13:20
jnthn 0 for owner and SC is fine 13:22
The flags are more interesting
FROGGS so it is an mvmobject?
jnthn 0 is actually a valid flag value.
And yeah, it would be if that's really right
FROGGS yeah
jnthn so you can try casting to (MVMObject *)
And looking at ->st
FROGGS ohh
jnthn If that is valid, look under REPR and you can see what kind of representation the object has. 13:23
FROGGS p *(*(MVMObject *)item)->st
$10 = {header = {owner = 0, flags = 42, size = 168, forwarder = 0x1a8ad80, sc = 0x1eddf10}, REPR = 0x7ffff7dd1060 <this_repr>, REPR_data = 0x4f121e0, size = 56, HOW = 0x20b4330,
WHAT = 0x1aa03a0, method_cache = 0x0, vtable = 0x0, type_check_cache = 0x0, vtable_length = 0, type_check_cache_length = 0, mode_flags = 0, type_cache_id = 0,
invoke = 0x7ffff7a19bd0 <MVM_6model_invoke_default>, container_spec = 0x0, container_data = 0x0, invocation_spec = 0x0, boolification_spec = 0x1fc1f00, WHO = 0x7ffff6a323b0,
hll_owner = 0x1eb2540, hll_role = 0}
name = 0x7ffff7a60dad "P6opaque" 13:24
ID = 5
jnthn: what is MVMuint16 mi; ? 13:56
13:57 colomon joined
FROGGS can I peek&poke it somehow else to get more information? 14:09
timotimo good day, mister! i can tell you're in need of anticipation and conjecture at extremely affordable prices! 14:10
FROGGS: can i interest you in the desire to find out what is in this struct? 14:11
so long as you never find out, it could be anything!
we guarantee that whatever you expect to be in the struct is probably more interesting than what is actually inside.
FROGGS huh? 14:17
ohh dear, when I insert say statements in m-BOOTSTRAP.nqp, the error goes away >.< 14:24
hoelzro I had a bug of that variety last week! 14:25
turns out I was reading from a socket with O_NONBLOCK on and no data was coming through 14:26
FROGGS well, I hope that is not the case here :o)
hoelzro indeed 14:27
jnthn FROGGS: mi = multiple inheritance 14:42
FROGGS ahh, it is true btw
hoelzro what is?
FROGGS mi of that object which explodes in the gc 14:43
jnthn oh... 14:44
wtf, where do we use MI in NQP...
Or bootstrap...
FROGGS I think it happens in the huge begin block in m-BOOTSRAP.nqp, line 569 to 2229
because I can say() something to the last line of that block, but the say() right outside of it explodes 14:45
(weirdly)
jnthn FROGGS: Well, you've done enough changes by then to throw off all kinds...
FROGGS: Anyway, look down the stack
You should see a call to process_worklist? 14:46
FROGGS I see my shoes
hold on
yes 14:47
#3
and I see MVM_args_get_pos_obj, for MoarVM's HEAD^ there showed up MVM_args_slurpy_positional 14:49
so I guess it has something to do with positional args
jnthn Well, what is immediately above process_worklist? 14:50
FROGGS #2 MVM_panic
or do you mean #4? 14:51
jnthn no, that's below :P
FROGGS MVM_gc_collect
:o)
jnthn Right, taht one :)
If you have a line number for where you are in there, take a look
It calls process_worklist many times...
And there's a comment above each saying what it's doing
What comment is above where it fails for you? 14:52
FROGGS lie 73
jnthn cake 73
FROGGS /* Add permanent roots and process them; only one thread will do
* this, since they are instance-wide. */
jnthn o.O
14:52 jnap joined
jnthn OK, another question 14:53
look at tc->gc_seq_number or similar
Can you see a conditional breakpoint at the start of MVM_gc_collect that will be hit on that number - 1?
And get the stack trace for the *previous* GC run?
FROGGS do you mean tc->gc_work_count by any chance? 14:57
jnthn no 14:58
FROGGS ahh
jnthn should be some kind of sequence number...
FROGGS it hangs of ->instance
jnthn oh
right, it's not thread-specific
FROGGS 170
okay...
jnthn :) 14:59
FROGGS break /home/froggs/dev/MoarVM/src/gc/collect.c:72 if tc->instance->gc_seq_number == 169 15:01
hit that now
and I see the bt
jnthn what's le bt? 15:02
FROGGS gist.github.com/FROGGS/d21a4bdc2753deff984e
jnthn wonders what's at interp.c:2289 15:07
jnthn looks on github...
(on classrom computer..> :))
FROGGS MVMObject *box = REPR(type)->allocate(tc, STABLE(type)); 15:08
in box_s
it should MVMROOT type, right?
same for box_i and _n
timotimo you fixed it? :) 15:09
FROGGS let's see if that helps :o)
jnthn no, 'cus it never mentions type again after the call that can allocate 15:10
FROGGS meh
jnthn If box_s was to blame, I kinda suspect we'd be seeing a lot more issues too... 15:11
The fact it comes from a perm root is very odd though 15:12
Antoher idea
Breakpoint it like you did
Once it fires, set a breakpoint in the roots.c function to add a perm root
And see if any get added
(and why)
FROGGS it compiled the setting btw 15:13
15:14 jnap1 joined
FROGGS but reverted, and will now add the breakpoint 15:14
jnthn The MVMROOT helped? o.O 15:15
FROGGS yes 15:16
jnthn wtf
FROGGS maybe just hides the problem
jnthn I'd guess so
FROGGS it does not hit the breakpoint MVM_gc_root_add_permanent 15:18
jnthn ok 15:19
Hmmmm
FROGGS I'll try MVM_gc_root_add_permanents_to_worklist
jnthn well, that is hit int he gc 15:20
FROGGS k
15:28 jnap joined
FROGGS jnthn: I think `type` needs to be temp_push'd in MVM_args_slurpy_named like in MVM_args_slurpy_positional 15:40
jnthn: btw, I don't think that my changes to interp.c helped, I just guess the m-BOOTSTRAP.moarvm was still in place from a successful build 15:49
but good to know that can build in 176s after that :o) 15:50
jnthn FROGGS: ah, ok 16:14
decommute now; bbiab
16:16 jnap joined 16:17 benabik joined
FROGGS jnthn: I really think that this patch is valid: gist.github.com/FROGGS/32d36a468e592eb0885e 16:21
does not help though 16:22
16:26 jnap joined 16:27 jnap joined 16:37 BenGoldberg joined 16:39 FROGGS[mobile] joined 16:47 jnap joined 16:50 colomon joined
jnthn FROGGS[mobile]: You'd really hope so...but... :/ 17:00
Look at what box_slurpy_named does :/ 17:01
It just uses type for its own means :/
17:19 benabik joined
FROGGS[mobile] ahh, that explains it 17:20
jnthn: if you feel like reviewing, there is a branch about labels in nqp *cough* :o) 17:36
jnthn hmm 17:37
Maybe later...
jnthn found teaching rather tiring
Dinner will either make me awaker or give me a food coma... :)
FROGGS[mobile] hehe 17:38
jnthn ponders what to nom
FROGGS[mobile] I'll have ham&eggs with onions and bread 17:39
17:54 lizmat joined 17:55 ssutch joined 18:14 tgt joined 18:15 FROGGS joined 18:18 colomon joined 18:36 benabik joined 18:58 jnap joined 19:11 BenGoldberg joined 19:16 jnap joined
FROGGS jnthn: is that correct that I can dump 336 bytes from 0x20b4330? gist.github.com/FROGGS/fcc7d25640eb12ec46fa 19:23
jnthn: if that is the case: the dump contains "$!positional_delegate" 19:24
which would be rakudo/src/gen/m-BOOTSTRAP.nqp:606: Attribute.HOW.add_attribute(Attribute, BOOTSTRAPATTR.new(:name<$!positional_delegate>, :type(int), :package(Attribute)));
ohh, or it is the line about: nqp::bindattr_i($attr, Attribute, '$!positional_delegate', $positional_delegate); 19:25
I guess I am reading junk 19:48
diakopter o_O 19:50
jnthn back from Indisk and a nice walk in -1 :) 20:02
20:27 jnap joined 20:36 eternaleye joined 20:40 colomon joined 21:04 FROGGS joined 22:19 colomon joined 22:36 jnap joined
timotimo FROGGS: you didn't find out what was causing the trouble yet? 22:37
FROGGS timotimo: no 22:48
timotimo builds stuff 22:49
jnthn We get a bit further into the optimize, then hit something null... 22:55
(after thing I pushed a moment ago)
need to sleep now though
&
timotimo gnite jnthn :)
Object does not exist in serialization context - that's not the error i should be getting? 23:01
trying to build src/gen/m-BOOTSTRAP.nqp 23:02
Internal error: invalid thread ID in GC work pass - huh? 23:08
currently trying to rebuild with an unoptimized moar 23:16
i wonder how far we get if we do --optimize=off
if i even get to stage parse this time 23:17
yes, i get to stage parse this time
shouldn't i be seeing at least two moar threads? isn't our gc multi-threaded? 23:19
or is that only the case in the gcorch branch?
Segmentation fault (core dumped) 23:25
there's an atpos_o whose object register is apparently a null pointer, so that's probably what jnthn was seeing
timotimo not sure how to debug 23:31
23:36 colomon joined
timotimo Error while compiling op replace: No registered operation handler for 'replace' - maybe i could do this? :3 23:38
23:44 lizmat joined 23:48 woolfy joined 23:51 d4l3k_ joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!