It was not possible to build the Objective C library shared with a.out, because the linker would generate symbol relocation warnings that Bruce didn't like. With ELF, I get no such warnings, so I've put a conditional in to building that will generate a shared lib for ELF, but not for a.out. Fix: =================================================================== RCS file: /usr/local/cvsroot/FreeBSD/src/gnu/lib/libobjc/Makefile,v retrieving revision 1.3 How-To-Repeat: 1) Apply patches 2) cd /usr/src/gnu/lib/libobjc 3) make OBJFORMAT=elf
In <199809021617.MAA14165@natasya.kublai.com>, shmit@kublai.com wrote: > It was not possible to build the Objective C library shared with > a.out, because the linker would generate symbol relocation warnings > that Bruce didn't like. With ELF, I get no such warnings, so I've > put a conditional in to building that will generate a shared lib > for ELF, but not for a.out. Do you really think that makes sense? Remember that each Objective-C method call calls a function from the runtime and making it shared means one pointer indirection more, with the usual bad cache effects. Here is a benchmark running small methods, smaller than a method normally is, i.e. just adding to an instance variable. I expect this benchmark not to show any cache trashing effects that a real application may encounter. This is an aout system. Sorry for the German strings. libobjc statically linked: 1.81 s (99.9%): `call auf id (aufwaermrunde)' 1.80 s (99.5%): `call auf id' 1.76 s (99.9%): `call auf id, 4. Subclasse' 1.76 s (100.0%): `call auf id, 3. Subclasse (vererbte Message)' 1.61 s (97.8%): `call auf id, 4. Subclasse ohne Parameter' 1.81 s (99.9%): `call auf id' 0.84 s (99.9%): `call auf id, 4. Subcl. ueber selector mit parameter' 0.68 s (99.9%): `call auf id, 4. Subcl. ueber selector ohne parameter' 1.86 s (100.0%): `call auf id, 4 Subclassen' 1.82 s (100.0%): `call auf declared' 3.63 s (100.0%): `call auf id mit id' libobjoc dynamically linked: 2.20 s (100.0%): `call auf id (aufwaermrunde)' 2.18 s (100.0%): `call auf id' 2.18 s (100.0%): `call auf id, 4. Subclasse' 2.20 s (98.6%): `call auf id, 3. Subclasse (vererbte Message)' 1.97 s (99.0%): `call auf id, 4. Subclasse ohne Parameter' 2.20 s (99.7%): `call auf id' 0.83 s (95.3%): `call auf id, 4. Subcl. ueber selector mit parameter' 0.63 s (99.4%): `call auf id, 4. Subcl. ueber selector ohne parameter' 2.29 s (99.6%): `call auf id, 4 Subclassen' 2.14 s (100.0%): `call auf declared' 4.69 s (99.7%): `call auf id mit id' The lib is < 80 KB. That isn't worth the slowdown, IMHO. The right thing might be to pull the method lookup functions into a seperate library that is static only and the rest into a dynamic library, but I think that will break most application Makefiles respectivly configure scripts. Opinions? If noone objects, I would leave it disabled, but change the string from NOPIC= does not work to NOPIC= works, but method lookup slowdown is significant Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer BSD User Group Hamburg, Germany http://www.bsdhh.org/
On Mon, Sep 07, 1998 at 06:00:41PM +0200, Martin Cracauer wrote: > The lib is < 80 KB. That isn't worth the slowdown, IMHO. You are probably correct. I hadn't done any timings to gauge the effects of the slowdown. I'm not sure whether or not it's a good idea anymore. Without the shared bits, you lose when changing base objects between revisions, which is one of Objective C's strong points (due to it's run-time indirection of methods). I don't think you run into the FBC that C++ does. Unfortunately, you lose on method call overhead. > The right thing might be to pull the method lookup functions into a > seperate library that is static only and the rest into a dynamic > library, but I think that will break most application Makefiles > respectivly configure scripts. This is the right thing to do. But: 1) This is GNU stuff, and I'm not particularly willing to maintain libobjc seperately from GNU (nor do I think the FreeBSD project is willing). So I'd have to write my own, or find another implementation (preferably with a nice BSD copyright). 2) Even if I were willing, the only way I can see it being done without breaking everybody's stuff (as you've noted) would be to make libobjc contain the method lookup function and link it statically, but have it call dlopen() to find the object definitions. This would require that all ObjC apps be compiled shared, which wouldn't be horrific, but smacks to much of Solaris facism for my taste. -bjc
In <19980909003452.42389@kublai.com>, Brian Cully wrote: > On Mon, Sep 07, 1998 at 06:00:41PM +0200, Martin Cracauer wrote: > > The lib is < 80 KB. That isn't worth the slowdown, IMHO. > > You are probably correct. I hadn't done any timings to gauge the > effects of the slowdown. I'm not sure whether or not it's a good > idea anymore. Without the shared bits, you lose when changing base > objects between revisions, which is one of Objective C's strong > points (due to it's run-time indirection of methods). Hm, I think I would prefer to link statically exactly for that reason: The compiler generates code that depends on one specific method lookup implementation. You might loose all your working binaries compiled with an older compiler when you upgrade to a newer compiler+runtime system if libobjc is statically linked. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 Paper: (private) Waldstrasse 200, 22846 Norderstedt, Germany
State Changed From-To: open->closed Shared lib is too costly for ObjC message calls. Comment in Makefiles changed to reflect reality.