From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62736 invoked by alias); 1 Apr 2019 13:39:15 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 62722 invoked by uid 89); 1 Apr 2019 13:39:14 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=roots, H*i:sk:alpine., globally, gladly X-HELO: mail-qt1-f193.google.com Received: from mail-qt1-f193.google.com (HELO mail-qt1-f193.google.com) (209.85.160.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 01 Apr 2019 13:39:12 +0000 Received: by mail-qt1-f193.google.com with SMTP id w30so10528266qta.8 for ; Mon, 01 Apr 2019 06:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=jHYTIgOn8ISd8R1R7zhBV4GJ3dyCtacakIjwIVulC8w=; b=XxCKARpPZOOMqZvCcHqcQs78LquI7wU9+LOknSdxxhC7ykVJTeUTu7TAIO698YU3eK 49e5Zhis24Inl0wq9Lpvf6mzvyrHmz0tGUUeFVxyW6HAzbipPtlxNu3cz1dDt4+CDFWI 4v9b1Kf4RvweO52MRUdubocNldWtgvA340rGNMUxs2fSnb/SIpzZ/x6ndGvxeQWBO/iv SM3LjWoAmuAeABk2mu3OV/neX2wz7CCWM30foHMQhVx0KKY6aBg69bca7T1C67+NPgkc lguU1FioMG8lr5JDbWj+89m05vBPMtOnhiNYJ72s8GnhHelCM4JzUoS8NQdFqZD+GA8i +Hjw== Return-Path: Received: from [192.168.1.101] (173-230-163-230.cable.teksavvy.com. [173.230.163.230]) by smtp.googlemail.com with ESMTPSA id k140sm5278315qke.9.2019.04.01.06.39.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Apr 2019 06:39:09 -0700 (PDT) Subject: Re: GSOC Proposal To: Richard Biener Cc: GCC Development References: <4327491a-395b-bee0-145a-eddd8f64b0ba@gmail.com> <63e78666-ceca-94d8-9ac4-101130afab4c@gmail.com> <70316c90-b241-3f88-56d8-9e59f3eac0ee@gmail.com> From: nick Message-ID: <038afc5c-85fa-8d78-5b84-289207c7b17f@gmail.com> Date: Mon, 01 Apr 2019 13:39:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00007.txt.bz2 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 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 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 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. Thanks, Nick