Re: GSOC Proposal

[Richard Biener <rguenther@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 8280 bytes --]

On Mon, 1 Apr 2019, nick wrote:

> 
> 
> On 2019-04-01 5:56 a.m., Richard Biener wrote:
> > On Fri, 29 Mar 2019, nick wrote:
> > 
> >>
> >>
> >> On 2019-03-29 10:28 a.m., nick wrote:
> >>>
> >>>
> >>> On 2019-03-29 5:08 a.m., Richard Biener wrote:
> >>>> On Thu, 28 Mar 2019, nick wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>> On 2019-03-28 4:59 a.m., Richard Biener wrote:
> >>>>>> On Wed, Mar 27, 2019 at 6:31 PM nick <xerofoify@gmail.com> wrote:
> >>>>>>>
> >>>>>>> Greetings All,
> >>>>>>>
> >>>>>>> I've already done most of the work required for signing up for GSoC
> >>>>>>> as of last year i.e. reading getting started, being signed up legally
> >>>>>>> for contributions.
> >>>>>>>
> >>>>>>> My only real concern would be the proposal which I started writing here:
> >>>>>>> https://docs.google.com/document/d/1BKVeh62IpigsQYf_fJqkdu_js0EeGdKtXInkWZ-DtU0/edit?usp=sharing
> >>>>>>>
> >>>>>>> The biography and success section I'm fine with my bigger concern would be the project and roadmap
> >>>>>>> section. The roadmap is there and I will go into more detail about it in the projects section as
> >>>>>>> need be. Just wanted to known if the roadmap is detailed enough or can I just write out a few
> >>>>>>> paragraphs discussing it in the Projects Section.
> >>>>>>
> >>>>>> I'm not sure I understand either the problem analysis nor the project
> >>>>>> goal parts.  What
> >>>>>> shared state with respect to garbage collection are you talking about?
> >>>>>>
> >>>>>> Richard.
> >>>>>>
> >>>>> I just fixed it. Seems we were discussing RTL itself. I edited it to 
> >>>>> reflect those changes. Let me know if it's unclear or you would actually 
> >>>>> like me to discuss some changes that may occur in the RTL layer itself.
> >>>>>
> >>>>>
> >>>>> I'm glad to be more exact if that's better but seems your confusion was 
> >>>>> just what layer we were touching.
> >>>>
> >>>> Let me just throw in some knowledge here.  The issue with RTL
> >>>> is that we currently can only have a single function in this
> >>>> intermediate language state since a function in RTL has some
> >>>> state in global variables that would differ if it were another
> >>>> function.  We can have multiple functions in GIMPLE intermediate
> >>>> language state since all such state is in a function-specific
> >>>> data structure (struct function).  The hard thing about moving
> >>>> all this "global" state of RTL into the same place is that
> >>>> there's global state in the various backends (and there's
> >>>> already a struct funtion 'machine' part for such state, so there's
> >>>> hope the issue isn't as big as it could be) and that some of
> >>>> the global state is big and only changes very rarely.
> >>>> That said, I'm not sure if anybody knows the full details here.
> >>>>
> >>>> So as far as I understand you'd like to tackle this as project
> >>>> with the goal to be able to have multiple functions in RTL
> >>>> state.
> >>>>
> >>>> That's laudable but IMHO also quite ambitious for a GSoC
> >>>> project.  It's also an area I am not very familiar with so
> >>>> I opt out of being a mentor for this project.
> >>>>
> >>> While I'm aware of three areas where the shared state is an issue
> >>> currently:
> >>> 1, Compiler's Proper
> >>> 2. The expand_functions 
> >>> 3. RTL
> >>> 4.Garbage Collector
> >>>
> >>> Or maybe a project to be more
> >>> explicit about regions of the code that assume that the garbage-
> >>> collector can't run within them?[3] (since the GC is state that would
> >>> be shared by the threads).
> >>>
> >>> This is what we were discussing previously and I wrote my proposal for
> >>> that. You however seem confused about what parts of the garbage collector
> >>> would be touched. That's fine with me, however seems you want be to
> >>> be more exact about which part  is touched.
> >>>
> >>> My questions would be as it's changed back to the garbage collector project:
> >>> https://docs.google.com/document/d/1BKVeh62IpigsQYf_fJqkdu_js0EeGdKtXInkWZ-DtU0/edit
> >>>
> >>> 1. Your confusion about which part of the garbage collector is touched doesn't
> >>> really make sense s it's for the whole garbage collector as related to shared
> >>> state?
> >>> 2. Injection was my code here in phase 3 for the callers of the new functions or
> >>> macros, perhaps this is not needed as the work with the garbage collector is enough?
> >>> 3. Am I not understanding this project as I thought I was in the proposal I wrote?
> >>>
> >>> Seems your more confusing my wording probably so I'm going to suggest one of 
> >>> two things here:
> >>> a) I'm going to allow you to make comments with what's confusing you and
> >>> it needs that's the issue here more than anything else so I sent you 
> >>> a link and please comment where you are having issues with this not
> >>> be clear for you:
> >>> Or maybe a project to be more
> >>> explicit about regions of the code that assume that the garbage-
> >>> collector can't run within them?[3] (since the GC is state that would
> >>> be shared by the threads).
> >>> as that's the actual project
> >>>
> >>> b) Just comment here about the wording that's an issue for you or
> >>> where you want more exact wording
> >>>
> >>> Sorry and hopefully this is helps you understand where I'm going,
> >>> Nick
> >>>
> >>>> Richard.
> >>>>
> >>>>> Nick
> >>>>>>> Any other comments are welcome as well as I write it there,
> >>>>>>> Nick
> >>>>>
> >>
> >> Richard,
> >>
> >> Seems your right touching the complete garbage collector is too much. I'm
> >> just looking at the users of the garbage collector and it seems one of the
> >> major ones is pre compiled headers.
> >>
> >> I've narrowed it down to that. My own real final concern is two things:
> >> 1. Does it make sense to you in my writing?
> >> 2. Should callers inject the information for state sharing as required
> >> as that seems better or is it better for the garbage collector to  store
> >> the state sharing flags,marcos and functions internally for this.
> >>
> >> Thanks and seems I was over thinking the last proposal it's too much:),
> > 
> > Nick,
> > 
> > as I've previously explained the garbage collector (and 
> > precompiled-headers) workings are understood well and its state
> > is already annotated everywhere.  What I do not understand is
> > what "global state" with respect to parallelization in GCC you
> > refer to when you write about the garbage collector and how
> > annotating helps parallelization.  The garbage collector itself
> > is only an issue for parallelization as far as it is not
> > thread-safe at the moment.  Collection already only happens
> > at very specific points where it is known to be safe.
> > 
> > Richard.
> > 
> Well I'm talking about the shared roots of this garbage collector core state 
> data structure or just struct ggc_root_tab.
> 
> But also this seems that this to be no longer shared globally if I'm not mistaken 
> or this:
> static vec<const_ggc_root_tab_t> extra_root_vec;
> 
> Not sure after reading the code which is a bigger deal through so I wrote
> my proposal not just asking which is a better issue for not being thread
> safe. Sorry about that.
> 
> As for the second question injection seems to not be the issue or outside
> callers but just internal so phase 3 or step 3 would now be:
> Find internal callers or users of x where x is one of the above rather
> than injecting outside callers. Which answers my second question about
> external callers being a issue still.
> 
> Let me know which  of the two is a better issue:
> 1. struct ggc_root_tabs being shared
> 2.static vec<const_ggc_root_tab_t> extra_root_vec; as a shared heap or
> vector of root nodes for each type of allocation
> 
> and I will gladly rewrite my proposal sections for that
> as needs to be reedited.

I don't think working on the garbage collector as a separate
GSoC project is useful at this point.  Doing locking around
allocation seems like a good short-term solution and if that
turns out to be a performance issue for the threaded part
using per-thread freelists is likely an easy to deploy
solution.

Richard.

-- 
Richard Biener <rguenther@suse.de>
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany;
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah; HRB 21284 (AG Nürnberg)