Post closed tickets in your report. | Note: This channel is for our weekly status meetings (Tuesdays at 19:30 UTC); you probably want #parrot instead. | irclog: irclog.perlgeek.de/
Set by moderator on 19 March 2012.
01:06 ilbot2 joined
moderator Post closed tickets in your report. | Note: This channel is for our weekly status meetings (Tuesdays at 19:30 UTC); you probably want #parrot instead. | irclog: irclog.perlgeek.de/
01:34 contingencyplan joined 04:12 alvis joined 04:29 alvis left 09:15 lucian joined 11:47 alvis joined 12:42 bluescreen joined 15:20 bluescreen joined 16:11 whiteknight joined
whiteknight WHAT I DID: 16:18
* Getting ready for GSOC. Our application got accepted. I've been filling out forms and writing proposal ideas on github in preparation.
* Working on the remove_sub_flags branch. All coretests pass. Fixing t/library/* and t/language/* tests, most of which are using old load_bytecode_s and load_language_s opcodes. Things that are updated to use the new code seem to work perfectly.
* Planning for another round of IMCC cleanups, and creating a new packfile-write API. Input welcome.
WHAT I WILL DO: 16:19
* Keep working on remove_sub_flags branch. I would like to get it ready for broad testing within the next week or two. I do not have a merge timeline yet, we won't rush it. We want to make sure NQP and Rakudo work fine with it before doing anything.
* Prepare patches for NQP-rx, Winxed and maybe NQP to work with the new branch.
* Talk to a few prospective GSOC students about project ideas
16:22 contingencyplan joined 18:09 benabik joined 18:58 bluescreen joined 19:26 kid51 joined
Util # Done: Nothing. 19:30
# Plan to do: Set up wiki page today for Parrot/Perl6 hackathon at YAPC::NA::2012
# Blockers: $WORK
.end
Hello 19:31
benabik hi
Util The first week or two after the time change, we have low attendance. 19:33
whiteknight hello
I think cotto might not be here, he's at a conference
benabik It's actually slightly easier for me to be here on DST. :-D 19:34
Util Which conference, whiteknight?
benabik A Drupal conf, I think.
whiteknight yeah, something with Drupals 19:36
Util Looks like the dates of YAPC::NA are 1/2-way between start of GSOC coding and mid-term evaluation. 19:37
benabik That's about what it was last year, wasn't it? 19:38
Util We should encourage GSOC students&mentors to come to YAPC for extra interaction. 19:39
benabik: I think so.
benabik It was very good last year. I'll be unable to this year, sadly. 19:40
(Even assuming I'm a student this year.)
whiteknight Where is YAPC this year?
Util GSOC students might not be aware (unless we tell them) that YAPC can grant scholarships to help with travel and admission. 19:41
Madison
benabik !
whiteknight oh, yeah, ain't no way I'm making it to Madison
benabik That would have been helpful.
Util Yet Another Perl Conference : North America - Madison, Wisconsin - June 13-15, 2012
whiteknight: You are in Philadelphia? benabik: Where are you based? 19:42
benabik Util: Rochester, NY
whiteknight Phily 19:43
Util I am in east-central Alabama.
I plan to attend. My wife Sarah is trying to come, too. She has been wanting to see a YAPC for several years now. 19:44
benabik I'd really love to come, but with a kid scheduled for the end of June, trying to vanish mid-June would probably not go over well with the wife. 19:45
Util benabik: indeed!
My 2nd grandchild is due August 1, but we should be OK to travel. 19:47
whiteknight benabik: your first kid? 19:48
benabik whiteknight: Yeah. Busy summer ahead.
whiteknight the extra GSOC money will come in handy with the myriad baby expenses, at least
benabik It's not really "extra" so much as "required summer job". :-D 19:49
whiteknight :)
benabik I need something that spans between my assistantships.
whiteknight okay, it looks like we're the only three people at the meeting. Are there any questions before we wrap this up and pretend it never happened? 19:55
nine yep
benabik four!
whiteknight nine: you have the floor
benabik (ah-ha-ha)
nine I think, I'll need some whiteknight time this week
whiteknight We'll talk to him, see what he can do 19:56
what do you need?
nine Proxied calls can cause garbage collection which would be catastrophic if run from the wrong thread. Also the data owning thread might just be running GC as well... 19:57
My only idea to maybe solve this is adding a lock to the GC but it's hard to say if that would be enough and it might be negative for single threaded performance. Maybe you got some of your great ideas handy. 19:58
whiteknight GC only runs on the main thread? 20:00
nine Every interp (and thus thread) runs its own GC. Also I'm still not 100 % decided if I should run proxied PMC methods with the caller's interp or the proxied one. Everything is simple with an Integer PMC, but starts to get quite complicated with things like Sub. 20:02
Just to be clear: I very much appreciate anyone's input on this. Just asking whiteknight specifically, because my work is based on his ideas. 20:03
whiteknight I suggest running the method on the calling thread. The invocant is already proxied there so all accesses should be safe 20:04
find_method on the proxy is going to have to return a clone of the Sub, since Sub is stateful
it shouldn't be, but it currently is
nine It would certainly make the whole GC problem simpler. But it makes the question more complicated if a method should return a PMC as is, or a new Proxy to the PMC. 20:05
whiteknight return PMC as is. If the PMC originally came from a different thread, it would be a proxy already
if the PMC was created on the current thread, return it directly 20:06
nine No it wouldnt
whiteknight wouldn't?
nine If I have a proxy to a ResizablePMCArray and do a shift, it would simply forward the shift VTABLE call to the array and thus return an unproxied PMC belonging to the other thread
whiteknight that proxies vtable call doesn't automatically proxy results? 20:08
nine It does right now because it runs the forwarded calls with the proxied PMC's interpreter. If I run them with the calling thread's interp, I could no longer be sure that all PMC results originate from the foreign interp. So I could no longer unconditionally create proxies for these results. 20:10
Any PMC which would be created during the forwarded call would be created on the thread's interp. Which would be nicer for GC, nicer for performance but Proxy would somehow have to know that it can pass it on as is. 20:11
whiteknight all this gets much easier if the PMC structure contains a "parent interp" pointer for easy identification 20:13
if (interp == pmc->parent_interp) all is good, etc 20:14
nine Which it even does on my threads_playground branch, because I use it to track down PMCs leaking to interps where they don't belong. 20:15
whiteknight make that a permanent part of the design for now
Add a macro PMC_IS_OWNED_BY(p, interp), so we can try to optimize it later 20:16
then in GC we can explicitly ignore all PMCs that don't belong. In the proxy we can auto-proxy results that are from a different interp, etc. A lot of logic becomes easier 20:19
nine I'm a bit worried about the cost, but don't have any numbers.
whiteknight I'm sure it will have a negative impact, but we save on a lot of costly logic elsewhere 20:20
If we wrap it up in a #ifdef PARROT_HAS_NINES_THREADS block, we can cut it out completely for single-threaded builds 20:21
and if we can clean out enough space, we might be able to store an interp_id in the PMC->flags field. Of course, that limits the number of interps we can have
We've got space there for at least 8 bits worth, if we have fewer than 256 interps 20:23
if we're on a machine with more than that many processor cores, maybe the extra pointer overhead is a non-issue
being able to do a this_interp == that_interp pointer comparison will be very fast compared to other kinds of lookups 20:25
nine Yep, the comparison doesn't worry me since it's only done during GC runs and in Proxy. Both situations where we don't really hurt a single threaded program. It's just adding 8 bytes to every single PMC that sounds expensive. 20:26
whiteknight the extra piece of mind in avoiding GC "catastrophy" may be worth the cost 20:27
and considering the whole lockless system was designed to be safer, that makes good sense 20:28
okay, I have to pack up and go home now. I'll be online later tonight to continue chatting 20:29
Util Any other business? 20:35
Adjourned. Thanks, everyone! 20:37
21:32 dukeleto joined
dukeleto waves 21:32
did i miss it? 21:33
benabik dukeleto: Very yes 21:35
By 2 hours or so
dukeleto lulz 21:46
ETOOLATE 21:50
22:35 whiteknight 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!