Re: [Jack-Devel] packed data structures in jack2

The point to pack memory is to allow a 64 bits server to be used with 32 bits clients or the contrary. Since shared memory is going to be used by "both sides", the only safe way we found was to use packed memory struct.

If 64/32 bits code cohabitation is not mandatory, then I guess "packed" can be disabled.

Stephane


Le 19 juil. 2012 à 05:41, Basil Nutmeg a écrit :

> Hello,
> 
> I found Jack2 was crashing on my ARM cpu, and I traced it down to a
> misuse of __attribute__((packed)).
> 
> This CPU doesn't support misaligned memory references. packed structs are
> supported, by having the compiler emit a longer sequence of instructions.
> However, consider this code from common/JackAtomicArrayState.h:
> 
> ... CAS(Counter1(old_val), Counter1(new_val), (UInt32*)&fCounter) ...
> 
> fCounter is a member of a class which is packed, and this happens to make
> it misaligned. Its address is taken and passed off to a different
> function, where it appears to the compiler to be an ordinary pointer. The
> compiler justifiably assumes the pointer is aligned, so it emits normal
> code, and the code crashes at runtime because the pointer isn't actually
> aligned.
> 
> Looking around, I was surprised to see that lots of classes in Jack2 are
> marked packed, for example classes like JackConnectionManager,
> JackClientControl, and JackEngineControl, and I'm puzzled.
> 
> Making JackEngineControl packed, for example, shrinks its nominal size
> from 1040 to 1032 (on this platform). It doesn't look like there are that
> many JackEngineControl instances floating around at runtime, so this isn't
> actually saving much memory. And it doesn't appear to be serialized
> anywhere. And on the down side, packed makes many of JackEngineControl's
> fields misaligned, making them slower to access.
> 
> Also, it's possible to shrink JackEngineControl to size 1032 just by
> reordering the fields, without using packed at all.
> 
> So I'm curious, why so much use of packed? Is there some reason I missed,
> or is it just a general attempt to save memory? If the latter, could I
> politely suggest this approach be reconsidered?
> 
> Thanks,
> 
> -- Basil
> 
> Jack-Devel mailing list
> [hidden]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

1342673701.13088_0.ltw:2,a <CC7EB2C5-C51E-46FF-AB54-0995A7F03AF1 at grame dot fr>