Hi, I think we are overloading the Layout references for garbage collection. If you are creating a reference (kindLayoutAfter) from A to B, that may not mean that you cannot garbage collect B for the end user. My thought on Layout references was that it only guarantees that atoms appear in Layout reference order. Why are we overloading this for Garbage collection (aside from saving space/code) ? We should create kindLive (or) some better name IMO for Garbage collection. With this the complex LayoutPass can be optional and would be meant only for users that need the LayoutReferences to specify layout of the image. We could come up with a simpler pass for Layout(to sort atoms by file ordinal). What do you think ? Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
I'm not sure if I understand the suggestion correctly, so let me double check. 1. You are thinking that layout-after should affect only on layouts, and garbage collector should ignore them. 2. Instead of layout-after, you suggested adding some other reference, so that all atoms from the same section will be handled as a group by the garbage collector. 3. By doing 1 and 2, we can make the LayoutPass simpler. Are the above points correct? On Tue, Jan 27, 2015 at 3:58 PM, Shankar Easwaran <shankare at codeaurora.org> wrote:> Hi, > > I think we are overloading the Layout references for garbage collection. > > If you are creating a reference (kindLayoutAfter) from A to B, that may > not mean that you cannot garbage collect B for the end user. > > My thought on Layout references was that it only guarantees that atoms > appear in Layout reference order. > > Why are we overloading this for Garbage collection (aside from saving > space/code) ? > > We should create kindLive (or) some better name IMO for Garbage > collection. With this the complex LayoutPass can be optional and would be > meant only for users that need the LayoutReferences to specify layout of > the image. > > We could come up with a simpler pass for Layout(to sort atoms by file > ordinal). > > What do you think ? > > Shankar Easwaran > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted > by the Linux Foundation > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150127/c89b3037/attachment.html>
On Tue, Jan 27, 2015 at 11:58 PM, Shankar Easwaran <shankare at codeaurora.org> wrote:> Hi, > > I think we are overloading the Layout references for garbage collection.one of the original points of layout references was for correct GC.> > If you are creating a reference (kindLayoutAfter) from A to B, that may not > mean that you cannot garbage collect B for the end user.The way we implement ELF semantics say you can't. We can only GC entire sections. You can't just yank an atom out of a layoutAfter chain.> > My thought on Layout references was that it only guarantees that atoms > appear in Layout reference order.GC is really simple right now. You just follow all references. Doing this would require checking each reference for if it's a "real" reference. While not a complicated change, it removes the purity of the graph model.> > Why are we overloading this for Garbage collection (aside from saving > space/code) ? > > We should create kindLive (or) some better name IMO for Garbage collection. > With this the complex LayoutPass can be optional and would be meant only for > users that need the LayoutReferences to specify layout of the image.The only current use of layout references is to preserve object file semantics. If we want to implement that some other way, we should remove LayoutReferences. We're already having performance issues in the linker, we don't really have room for any non-essential overhead. - Michael Spencer> > We could come up with a simpler pass for Layout(to sort atoms by file > ordinal). > > What do you think ? > > Shankar Easwaran > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by > the Linux Foundation >
On 1/28/2015 6:28 AM, Michael Spencer wrote:> On Tue, Jan 27, 2015 at 11:58 PM, Shankar Easwaran > <shankare at codeaurora.org> wrote: >> Hi, >> >> I think we are overloading the Layout references for garbage collection. > one of the original points of layout references was for correct GC. > >> If you are creating a reference (kindLayoutAfter) from A to B, that may not >> mean that you cannot garbage collect B for the end user. > The way we implement ELF semantics say you can't. We can only GC > entire sections. You can't just yank an atom out of a layoutAfter > chain.Garbage collection is disabled by default with GNU linker. I think, we should not run the LayoutPass unless :- * GC is enabled * There is a need of sorting atoms using LayoutReferences (reordering atoms using an order file) For all the default cases when GC is disabled, it should be enough that the layout pass sorts atoms by file ordinal, and ordinals of atoms within the file.>> My thought on Layout references was that it only guarantees that atoms >> appear in Layout reference order. > GC is really simple right now. You just follow all references. Doing > this would require checking each reference for if it's a "real" > reference. While not a complicated change, it removes the purity of > the graph model.Ok.>> Why are we overloading this for Garbage collection (aside from saving >> space/code) ? >> >> We should create kindLive (or) some better name IMO for Garbage collection. >> With this the complex LayoutPass can be optional and would be meant only for >> users that need the LayoutReferences to specify layout of the image. > The only current use of layout references is to preserve object file > semantics. If we want to implement that some other way, we should > remove LayoutReferences. We're already having performance issues in > the linker, we don't really have room for any non-essential overhead.I agree we should preserve object file semantics and LayoutReferences are able to already handle this and we should not design something else that adds more overhead. Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation