On Jun 15, 2013, at 01:37 , Marvin Humphrey <[email protected]> wrote:
> I think it would be: > > * For each unique class/method-name that is invoked somewhere in the DSO, > maintain a local copy of its offset variable in the .bss section of the > DSO (.bss = non-constant static variables, implicitly initialized to 0). > * During the initialization routine, assign the proper values to all local > OFFSET var copies. > * When invoking the method, access the local OFFSET var using a pc-relative > load. How would you find all unique class/method combinations used in a DSO? > I think we manage something like that right now for methods defined within the > current parcel, right Nick? But for methods defined in another parcel, the > offset var would be a global accessed via the GOT. On Mach-O, we only need a PC-relative load for offsets within the current parcel. On ELF systems, we always have to go through the GOT because of symbol interposition. It might be possible to avoid that using "protected" symbol visibility. > I don't think that scheme saves space, but it seems like the theoretical > minimum amount of indirection. Plus, the jump from the call site ought to > have decent branch prediction, particularly for a loop which invokes the same > method on the same object over and over. We could save more space by only using offsets for novel methods like I already proposed. This might have a negative effect on branch prediction, though. Nick
