From shmit@natasya.kublai.com Wed Sep 2 09:18:41 1998 Received: from coleridge.kublai.com (coleridge.kublai.com [207.96.1.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA16572 for ; Wed, 2 Sep 1998 09:18:40 -0700 (PDT) (envelope-from shmit@natasya.kublai.com) Received: from natasya.kublai.com (natasya.kublai.com [207.172.25.236]) by coleridge.kublai.com (8.8.8/8.8.8) with ESMTP id MAA00306 for ; Wed, 2 Sep 1998 12:17:38 -0400 (EDT) (envelope-from shmit@natasya.kublai.com) Received: (from shmit@localhost) by natasya.kublai.com (8.9.1/8.8.8) id MAA14165; Wed, 2 Sep 1998 12:17:38 -0400 (EDT) Message-Id: <199809021617.MAA14165@natasya.kublai.com> Date: Wed, 2 Sep 1998 12:17:38 -0400 (EDT) From: shmit@kublai.com Reply-To: shmit@kublai.com To: FreeBSD-gnats-submit@freebsd.org Subject: Patch to build Objective C library shared X-Send-Pr-Version: 3.2 >Number: 7811 >Category: gnu >Synopsis: Build Objective C library shared for ELF >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: closed >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Wed Sep 2 09:20:01 PDT 1998 >Closed-Date: Wed Sep 9 13:40:13 MEST 1998 >Last-Modified: Wed Sep 9 13:41:05 MEST 1998 >Originator: Brian Cully >Release: FreeBSD 3.0-CURRENT i386 >Organization: >Environment: FreeBSD 3.0 Current w/ ELF. >Description: 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. >How-To-Repeat: 1) Apply patches 2) cd /usr/src/gnu/lib/libobjc 3) make OBJFORMAT=elf >Fix: =================================================================== RCS file: /usr/local/cvsroot/FreeBSD/src/gnu/lib/libobjc/Makefile,v retrieving revision 1.3 diff -c -r1.3 Makefile *** Makefile 1997/02/22 15:43:02 1.3 --- Makefile 1998/09/02 16:13:22 *************** *** 7,13 **** --- 7,15 ---- LIB= objc NOMAN= sorry + .if ${OBJFORMAT} != "elf" NOPIC= does not work + .endif SRCS= archive.c class.c encoding.c hash.c init.c misc.c \ my_objects.c sarray.c selector.c my_sendmsg.c \ >Release-Note: >Audit-Trail: From: Martin Cracauer To: shmit@kublai.com, FreeBSD-gnats-submit@FreeBSD.ORG Cc: Subject: Re: gnu/7811: Patch to build Objective C library shared Date: Mon, 7 Sep 1998 18:00:41 +0200 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 http://www.cons.org/cracauer BSD User Group Hamburg, Germany http://www.bsdhh.org/ From: Brian Cully To: Martin Cracauer , FreeBSD-gnats-submit@FreeBSD.ORG Cc: Subject: Re: gnu/7811: Patch to build Objective C library shared Date: Wed, 9 Sep 1998 00:34:52 -0400 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 From: Martin Cracauer To: Martin Cracauer , FreeBSD-gnats-submit@FreeBSD.ORG Cc: Subject: Re: gnu/7811: Patch to build Objective C library shared Date: Wed, 9 Sep 1998 11:09:02 +0200 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 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 State-Changed-By: cracauer State-Changed-When: Wed Sep 9 13:40:13 MEST 1998 State-Changed-Why: Shared lib is too costly for ObjC message calls. Comment in Makefiles changed to reflect reality. >Unformatted: