only if the class heirarchy is from the same shared library as the field lookup... some language runtimes can cache the relocation e.g. when run in a loop if they have a way to invalidate the cache when an object size changes, others cannot...
On Mon, Jul 13, 2015 at 12:03 AM, Keean Schupke <[email protected]> wrote: > Is the overhead not eliminated in the link phase when ld.so replaces all the > relocation information with the absolute address loaded at? > > I would have thought after symbol relocation at link time (when the shared > object is loaded) the machine code executed at runtime should/could be the > same. > > Keean. > > On 13 Jul 2015 7:12 am, "Matt Rice" <[email protected]> wrote: >> >> Right, the objective-c approach to the fragile base class problem is >> to have an symbol which stores the offset of the subclass relative to >> the base class, and when the base class that symbol gets patched up to >> reflect the base classes new size, this requires an addition of the >> end_of_base_class+fields_offset, to access a field... they deem this >> an acceptable overhead, not going to really argue with that its >> constant at least... >> >> what I take umbrage with is that it puts you in a position where it is >> deemed acceptable to not know the actual shape of an object until >> runtime, and if you care or worse require that the size of an object >> at compile time *is* the size of an object at runtime, I find it an >> unacceptable position. >> >> On Sun, Jul 12, 2015 at 10:37 PM, Keean Schupke <[email protected]> wrote: >> > Really each Swift component is like a COM component and designed to be >> > dynamically loaded at runtime. >> > >> > On a unix/Linux platform its the equivalent of compiling every object as >> > a >> > separate shared object library. What swift does, like C# does for COM is >> > hide the boilerplate of the dynamic library loading, making it >> > automatic, >> > and hidden from the programmer. >> > >> > Objective-C is really two languages, a static 'C' fragment, and a >> > Smalltalk >> > fragment (in the square brackets). Where the COM like functionality is >> > handled by the Smalltalk fragment. Swift integrates these two parts into >> > a >> > single language. >> > >> > Keean. >> > >> > On 13 Jul 2015 2:24 am, "Matt Rice" <[email protected]> wrote: >> >> >> >> On Sun, Jul 12, 2015 at 1:56 PM, Jonathan S. Shapiro <[email protected]> >> >> wrote: >> >> > Matt: >> >> > >> >> > While size and offset unknowns may begin with a type variable, they >> >> > are >> >> > compounded both by combinatorics and by overload resolution. The >> >> > latter >> >> > especially in the presence of inlining. >> >> >> >> Precisely why the separate compilation strategy was limited to the set >> >> of types with known sizes and offsets, (or isolation between >> >> environments which can contain variables of :type, and actual type >> >> values... albeit pessimistically... there are some caveats where >> >> things really don't care and passing a shape as a parameter is >> >> adequate I don't have any answer for cases such as that yet >> >> really...), >> >> >> >> I don't really see this complication as adequate justification for >> >> post compilation relocation... though the separate compilation >> >> available is a bit weird compared to what we typically associate with >> >> the term I suppose... >> >> >> >> Anyhow, sorry for rambling off the topic of swift... >> >> _______________________________________________ >> >> bitc-dev mailing list >> >> [email protected] >> >> http://www.coyotos.org/mailman/listinfo/bitc-dev >> > >> > >> > _______________________________________________ >> > bitc-dev mailing list >> > [email protected] >> > http://www.coyotos.org/mailman/listinfo/bitc-dev >> > >> _______________________________________________ >> bitc-dev mailing list >> [email protected] >> http://www.coyotos.org/mailman/listinfo/bitc-dev > > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
