On Sat, Jun 22, 2013 at 8:10 PM, Marvin Humphrey <[email protected]> wrote: > Smalltalk-style messaging with or without method caching indeed solves the > fragile ABI problem for dynamic methods. > > For speed's sake, though, we accept that all method names must be resolved > statically to specific OFFSET vars.
OK, and we feel we already have dynamic methods reasonably solved. And if we were to take an accessor method to instance ivars, we could solve this as well, other than the unacceptable hit to performance? We're probably just defining differently, but I'm confused by 'statically' here. Static in the sense that the symbol names remain constant across version changes of the core? > We can add instance variables or methods now through the host. > > package MyObj; > use base qw( Clownfish::Object ); > ... > > What we can't do is access those methods or instance variables from C. The example is good, but not what I was thinking of. Perhaps we are thinking of "at runtime" differently, and likely my definition is wrong. I'm primarily thinking of runtime in terms of the runtime linker and any load time initialization we do upon loading an extension that has been compiled against an unknown version of the core. I guess the distinction does get fuzzy when dynamically loading libraries with interpreted language like Perl. In any case, when I refer to new methods and instance variables in this context, I mean new in that they were not present in the library the extension was initially compiled against. This library might be core Lucy, or might be another compiled user extension. As I think you feel, I don't think there is much to gain by allowing extensions to be compiled against a Perl subclass. At this point, I'm thinking only about binary to binary compatibility. > Potentially, we could add a mechanism to Clownfish for appending additional > instance variables to the ends of objects. We just have to know about them > when the VTable is first registered so that we can increase the > obj_alloc_size. But then this would still be fragile to the ordering of the parent struct? > I dunno. I can't see how such a thing is really needed, when the only thing > it buys us beyond what we have already is the ability to access unknown > instance vars from C. I agree that this is of limited interest. I don't think that allowing subclassing of host language classes in a compiled extension is necessary. I do think that you should be able to swap a host language class for the class that extension depends on. > The distinction I would make between what we're doing and a JIT is that none > of the dynamic capabilities we are implementing require us to create machine > code on the fly. Yes, there is that slight difference. Perhaps squint more? :) > Also, position-independent code is still fine, we don't need > to patch any call sites and the .text section of the DSO remains shareable > across multiple processes. This may be the part I've missed: do you have a solution you are comfortable with for dealing with instance variables, particularly the case where the order is changed in the compiled parent library from one version to another? I think that is where I'm stuck without resorting to the techniques used by dynamic language runtimes. --nate
