On Apr 18, 2010, at 8:13 PM, Michael Ash wrote:
As you can see, the offset of the ivar itself is referenced as a
linker symbol which will then get resolved at load time. And you can
see that no function calls take place.
For some reason I assumed that symbol held the Ivar struct. Which
woul
On Sun, Apr 18, 2010 at 10:58 PM, Kyle Sluder wrote:
> On Apr 18, 2010, at 6:52 PM, Michael Ash wrote:
>
>> If by "indirected through the runtime" you mean "accesses one global
>> variable to get an offset". It does not, as one might take your
>> comment to indicate, actually call any runtime fun
On Apr 18, 2010, at 6:52 PM, Michael Ash wrote:
If by "indirected through the runtime" you mean "accesses one global
variable to get an offset". It does not, as one might take your
comment to indicate, actually call any runtime functions.
If that's the case, how can the language support reord
On Sun, Apr 18, 2010 at 2:09 AM, Kyle Sluder wrote:
> On Sat, Apr 17, 2010 at 8:29 PM, Ben Haller
> wrote:
>> I don't think I'm crazy about this. There are many different subclasses,
>> so each subclass would have its own corresponding struct, and every ivar
>> access would go through an indire
On Sat, Apr 17, 2010 at 8:29 PM, Ben Haller
wrote:
> I don't think I'm crazy about this. There are many different subclasses,
> so each subclass would have its own corresponding struct, and every ivar
> access would go through an indirection; it sounds very confusing and messy.
> Not to say the
On 17-Apr-10, at 7:04 PM, Kyle Sluder wrote:
On Sat, Apr 17, 2010 at 2:01 PM, Charles Srstka
wrote:
How about just giving your object only one instance variable, which
is a pointer to a C struct, with all the object’s accessor methods
pointing to elements in the struct? Then, all you’d have
On Sat, Apr 17, 2010 at 2:01 PM, Charles Srstka
wrote:
> How about just giving your object only one instance variable, which is a
> pointer to a C struct, with all the object’s accessor methods pointing to
> elements in the struct? Then, all you’d have to do would be to swap out the
> struct fo
On Apr 17, 2010, at 8:34 AM, Ben Haller wrote:
>> Lastly, if your objects are so simple (direct subclasses or NSObject, no
>> pointer ivars, etc.), have you considered using plain C structs instead of
>> objects? Or C++ objects and collections? I'm not saying you necessarily
>> should use tho
> I think my approach, with the excellent modifications suggested by
> Ken Thomases, makes me less nervous than the others proposed, since it
> touches only my own ivars and makes no assumptions about the nature of
> the rest of the bits in the object.
OK, best of luck. I think that 64-bit
Gathering up a few loose ends...
On 17-Apr-10, at 11:11 AM, Paul Sanders wrote:
I reckon my scheme might actually be faster Ben, if you benchmark
it. Without the assert it's just a method call and a memcpy, which
the compiler knows the size of and can therefore optimise. Only you
can
> The question is: Is it documented as a fact you can rely on that this is
> the case? If not, I at least wouldn't rely on it for shipping code. Even
> if it was for an "at home" project I'd think about it long and hard.
> Tracking down subtle memory bugs caused by Apple deciding to move the
>
On Apr 17, 2010, at 9:53 AM, Uli Kusterer wrote:
> On 17.04.10 16:47, Ken Thomases wrote:
>> On Apr 17, 2010, at 9:37 AM, Paul Sanders wrote:
That is, retain counts are stored outside of the instance.
>>> In that case there is a danger that a pointer to whatever is referenced
>>> would be tr
Ben Haller (bhcocoa...@sticksoftware.com) on 2010-04-17 09:06 said:
>>> This should cast "individual" to void* before doing the pointer
>>> arithmetic, of course.
>>
>> And of course by "void*" you meant "uint8_t*". Pointer arithmetic
>> is undefined on voids... it happens to be supported by gcc
> No, you misunderstand. There is (in the scheme I'm vaguely recalling)
> _nothing_ inside the instances
> which holds or points to something which holds the retain count.
>
> There is another data structure entirely which maps from object addresses to
> a retain count.
Yes I see, that's also w
> AFAIK, CF objects store the retain count in an "ivar" (or a struct field to
> be exact) and
> standard Obj-C objects ref count is stored in an external hash collection
> (CFBasicHash on 10.6).
One might get away with it then, as presumably the hash key is the address of
the object and that i
On 17.04.10 16:47, Ken Thomases wrote:
On Apr 17, 2010, at 9:37 AM, Paul Sanders wrote:
That is, retain counts are stored outside of the instance.
In that case there is a danger that a pointer to whatever is referenced would
be transferred to the copy of the object, which is not what you want.
On Apr 17, 2010, at 9:35 AM, Jean-Daniel Dupas wrote:
> That said, this is an implementation details.
>
> IIRC, GnuStep used to store the retain count in 4 additional bytes allocated
> before each object.
>
> uint32_t *rc = (uint8_t *)self - 4;
Well, it's an implementation detail of which you
On Apr 17, 2010, at 9:37 AM, Paul Sanders wrote:
> > That is, retain counts are stored outside of the instance.
> In that case there is a danger that a pointer to whatever is referenced would
> be transferred to the copy of the object, which is not what you want.
No, you misunderstand. There is
> My understanding, which is vague and for which I have no references, is that
> it's handled in a manner similar to
> what was recently exposed via the associated references API (i.e.
> objc_setAssociatedObject and friends).
>
> That is, retain counts are stored outside of the instance.
In that
Le 17 avr. 2010 à 16:16, Ken Thomases a écrit :
> On Apr 17, 2010, at 8:53 AM, Paul Sanders wrote:
>
>> Something I've never been clear about though is
>> where an object's retain count is stored. This obviously
>> requires an iVar somewhere (in addition to isA), so there might
>> be a trap
On Apr 17, 2010, at 8:53 AM, Paul Sanders wrote:
> Something I've never been clear about though is
> where an object's retain count is stored. This obviously
> requires an iVar somewhere (in addition to isA), so there might
> be a trap for the unwary there [...]
My understanding, which is vag
en, based on the way that Ben is recycling
his objects.
> The init method has nothing to do with zeroing out instance variables.
> Object allocation is responsible for that.
Indeed. That's what lies behind the OP's predicament. If init did it, he
would not have to hack aroun
> As I mentioned in my post to Graham just now, doesn't your
> implementation assume that NSObject's only ivar is the isa
> pointer,
> though?
Actually, no. Because it makes a bitwise copy of a clean,
properly init'ed object it should work whatever trickery
NSObject (or any other parent class)
fe if the class has no pointers with ownership semantics among its instance
variables. See the discussion of object copying in the Memory Management Guide.
> This approach gives you the opportunity to end up with an object that is not
> just all zeroes (by way of the init method)
The init
On 17-Apr-10, at 9:14 AM, Paul Sanders wrote:
> Yep, it's a big win. Even if the default allocator does something
> similar (and I think you're right that a linked list of free
blocks of
> a given size is maintained by the malloc code, or something of that
> sort), this scheme avoids a fair
On 17-Apr-10, at 7:01 AM, Ken Thomases wrote:
On Apr 16, 2010, at 4:05 PM, Ben Haller wrote:
So I'm keeping an "unused pool" of these objects, and when I'm done
with an object I throw it into the pool, and when I need a new one
I grab one from the pool. I do these operations with inline
> Yep, it's a big win. Even if the default allocator does something
> similar (and I think you're right that a linked list of free blocks of
> a given size is maintained by the malloc code, or something of that
> sort), this scheme avoids a fair handful of method calls and function
> calls
On 16-Apr-10, at 6:34 PM, Paul Sanders wrote:
Another way might be to provide a method in each class or subclass
called, say, zeroIVars and code it as (typed in mail):
- (void) zeroIVars
{
static ThisClass *clean_instance_of_this_class;
assert ([self isMemberOfClass: [ThisClass class
3. bzero(individual + individualIvarsOffset, individualIvarsSize);
This should cast "individual" to void* before doing the pointer
arithmetic, of course.
And of course by "void*" you meant "uint8_t*". Pointer arithmetic
is undefined on voids... it happens to be supported by gcc & clang
This probably takes more time than allocating a new object :-)
My company uses it to scramble memory for invalidated objects that hang
around for a while, to force crashes if accessed (id object addresses
will be bogus).
David
---
void clearIvars(id obj)
{
unsigned int outCount = 0;
So, thoughts? Am I insane? Is the above scheme safe? Is there a
better way? Thanks for any feedback!
(I think this question is appropriate for cocoa-dev rather than the
objc-language list, but my apologies if I have posted to the wrong
forum...)
My question to you would be: have you p
On Apr 16, 2010, at 4:05 PM, Ben Haller wrote:
> So I'm keeping an "unused pool" of these objects, and when I'm done with an
> object I throw it into the pool, and when I need a new one I grab one from
> the pool. I do these operations with inline functions, so I can get a new
> object instan
>> 3. bzero(individual + individualIvarsOffset, individualIvarsSize);
>
> This should cast "individual" to void* before doing the pointer arithmetic,
> of course.
And of course by "void*" you meant "uint8_t*". Pointer arithmetic is undefined
on voids... it happens to be supported by gcc & cla
On 17/04/2010, at 7:05 AM, Ben Haller wrote:
> So, thoughts? Am I insane? Is the above scheme safe? Is there a better
> way? Thanks for any feedback!
>
> (I think this question is appropriate for cocoa-dev rather than the
> objc-language list, but my apologies if I have posted to the wron
ent: Friday, April 16, 2010 10:29 PM
Subject: Re: Zeroing out instance variables
> 3. bzero(individual + individualIvarsOffset, individualIvarsSize);
This should cast "individual" to void* before doing the pointer
arithmetic, of course.
> So, thoughts? Am I insane? Is the
3. bzero(individual + individualIvarsOffset, individualIvarsSize);
This should cast "individual" to void* before doing the pointer
arithmetic, of course.
So, thoughts? Am I insane? Is the above scheme safe? Is there a
better way? Thanks for any feedback!
I should note that the s
Hi all. I've got a situation where I need to reuse some Obj-C
objects. Basically, I'm allocating and deallocating these very
lightweight objects in staggering numbers, more or less continuously,
for minutes to hours at a time, and so the performance overhead of the
allocations really do
37 matches
Mail list logo
