Skip to content

Use specially-aligned types instead of packed structs#1

Open
basilnut wants to merge 3 commits into
sletz:masterfrom
basilnut:master
Open

Use specially-aligned types instead of packed structs#1
basilnut wants to merge 3 commits into
sletz:masterfrom
basilnut:master

Conversation

@basilnut
Copy link
Copy Markdown

Here's my proposed patchset for replacing packed structs with specially aligned types.

I've tested on x86 Linux and confirmed that the structs are compatible between 64-bit and 32-bit. The patch includes changes for MSVC, which I believe should work, but I have not tested it.

The patch includes some minor ABI breakage in jack's public headers; I've described the changes in detail in the commits. This breakage could be avoided, however it would require more complex changes.

I decided to introduce new typedefs only for types which actually differ between 32-bit and 64-bit, rather than all types. This reduced overall churn, though I recognize that it makes it somewhat more likely that someone in the future might add a field to a shared struct and forget to ensure proper alignment.

Let me know if you would like to see anything done differently. Or if you'd like to just forget it altogether I'll understand :-).

@sletz
Copy link
Copy Markdown
Owner

sletz commented Jul 25, 2012

Well this is quite a huge change, and it already breaks OSX version, that does not compile anymore after the first patch:

basilnut@628161b

Actually on OSX we have:

#if LP64
typedef unsigned int UInt32;
#else
typedef unsigned long UInt32;
#endif

and so your change does not work....

More generally, my feeling is that the whole idea is a bit invasive I also need to be sure it won't break on Windows 64 and 32 bit), so I think we should try it more slowly. Do you think you could restructure the patches a bit?

Stéphane

Le 22 juil. 2012 à 03:32, basilnut a écrit :

Here's my proposed patchset for replacing packed structs with specially aligned types.

I've tested on x86 Linux and confirmed that the structs are compatible between 64-bit and 32-bit. The patch includes changes for MSVC, which I believe should work, but I have not tested it.

The patch includes some minor ABI breakage in jack's public headers; I've described the changes in detail in the commits. This breakage could be avoided, however it would require more complex changes.

I decided to introduce new typedefs only for types which actually differ between 32-bit and 64-bit, rather than all types. This reduced overall churn, though I recognize that it makes it somewhat more likely that someone in the future might add a field to a shared struct and forget to ensure proper alignment.

Let me know if you would like to see anything done differently. Or if you'd like to just forget it altogether I'll understand :-).

You can merge this Pull Request by running:

git pull https://github.com/basilnut/jack2 master

Or you can view, comment on it, or merge it online at:

#1

-- Commit Summary --

  • Replace UInt32 etc. with uint32_t etc.
  • Delete some redundant macros and typedefs.
  • Add new typedefs to support 32/64 mixed mode.
  • Make internal types 32/64 clean.
  • Remove use of packed structs.

-- File Changes --

M common/JackActivationCount.h (8)
M common/JackAtomic.h (8)
M common/JackAtomicArrayState.h (30)
M common/JackAtomicState.h (38)
M common/JackClientControl.h (4)
M common/JackConnectionManager.h (24)
M common/JackEngineControl.h (10)
M common/JackEngineProfiling.h (16)
M common/JackFilters.h (20)
M common/JackFrameTimer.cpp (4)
M common/JackFrameTimer.h (8)
M common/JackGraphManager.cpp (16)
M common/JackGraphManager.h (4)
M common/JackMessageBuffer.h (2)
M common/JackNetAPI.cpp (6)
M common/JackPort.h (4)
M common/JackThread.h (4)
M common/JackTransportEngine.cpp (4)
M common/JackTransportEngine.h (6)
M common/JackTypes.h (17)
M common/jack/systemdeps.h (39)
M common/jack/types.h (30)
M common/shm.h (6)
M linux/JackAtomic_os.h (10)
M macosx/JackAtomic_os.h (4)
M macosx/JackCompilerDeps_os.h (14)
M macosx/JackMachThread.cpp (16)
M macosx/JackMachThread.h (24)
M macosx/coreaudio/JackCoreAudioAdapter.cpp (114)
M macosx/coreaudio/JackCoreAudioAdapter.h (10)
M macosx/coreaudio/JackCoreAudioDriver.cpp (160)
M macosx/coreaudio/JackCoreAudioDriver.h (12)
M macosx/coreaudio/TiPhoneCoreAudioRenderer.cpp (24)
M macosx/coreaudio/TiPhoneCoreAudioRenderer.h (6)
M macosx/coremidi/JackCoreMidiOutputPort.cpp (8)
M macosx/coremidi/JackCoreMidiOutputPort.h (4)
M macosx/coremidi/JackCoreMidiPhysicalOutputPort.cpp (2)
M macosx/iphone/iphone-faust.mm (28)
M posix/JackCompilerDeps_os.h (18)
M posix/JackPosixThread.h (2)
M posix/JackTypes_os.h (3)
M solaris/JackAtomic_os.h (2)
M tests/testAtomic.cpp (4)
M windows/JackAtomic_os.h (4)
M windows/JackCompilerDeps_os.h (31)
M windows/JackTypes_os.h (4)
M windows/JackWinThread.h (2)

-- Patch Links --

https://github.com/sletz/jack2/pull/1.patch
https://github.com/sletz/jack2/pull/1.diff


Reply to this email directly or view it on GitHub:
#1

@sletz
Copy link
Copy Markdown
Owner

sletz commented Jul 25, 2012

On Wed, Jul 25, 2012 at 07:17:29AM +0200, Stéphane Letz wrote:

Well this is quite a huge change, and it already breaks OSX version, that does not compile anymore after the first patch:

basilnut@628161b

Actually on OSX we have:

#if LP64
typedef unsigned int UInt32;
#else
typedef unsigned long UInt32;
#endif

and so your change does not work....

Oh wild. Well, that patch was just there because I didn't want to create
both jack_uint64_t and jack_UInt64, and because I thought it'd be
desirable anyway, but it seems I was wrong.

More generally, my feeling is that the whole idea is a bit invasive I also need to be sure it won't break on Windows 64 and 32 bit), so I think we should try it more slowly. Do you think you could restructure the patches a bit?

Ok. I've pulled that UInt32 patch out of My tree. Are there any other
changes you'd like to see?

Thanks,

-- Basil

@sletz
Copy link
Copy Markdown
Owner

sletz commented Jul 27, 2012

Le 26 juil. 2012 à 00:31, Basil Nutmeg a écrit :

On Wed, Jul 25, 2012 at 07:17:29AM +0200, Stéphane Letz wrote:

Well this is quite a huge change, and it already breaks OSX version, that does not compile anymore after the first patch:

basilnut@628161b

Actually on OSX we have:

#if LP64
typedef unsigned int UInt32;
#else
typedef unsigned long UInt32;
#endif

and so your change does not work....

Oh wild. Well, that patch was just there because I didn't want to create
both jack_uint64_t and jack_UInt64, and because I thought it'd be
desirable anyway, but it seems I was wrong.

More generally, my feeling is that the whole idea is a bit invasive I also need to be sure it won't break on Windows 64 and 32 bit), so I think we should try it more slowly. Do you think you could restructure the patches a bit?

Ok. I've pulled that UInt32 patch out of My tree. Are there any other
changes you'd like to see?

Thanks,

-- Basil

OK, OSX compilation now works again. And mixing 64 server and 32/64 bits clients seems to works correctly on OSX. I'll need to do some more tests. Compilation and tests on Windows have to be done again (probably not before a few days/week...) and ABI change issues have to be tested carefully (especially with the Harisson/Mixbus guys on Windows....)

Stéphane

@sletz
Copy link
Copy Markdown
Owner

sletz commented Jul 27, 2012

On Fri, Jul 27, 2012 at 12:18:05PM +0200, Stéphane Letz wrote:

Ok. I've pulled that UInt32 patch out of My tree. Are there any other
changes you'd like to see?

Thanks,

-- Basil

OK, OSX compilation now works again. And mixing 64 server and 32/64 bits clients seems to works correctly on OSX. I'll need to do some more tests. Compilation and tests on Windows have to be done again (probably not before a few days/week...) and ABI change issues have to be tested carefully (especially with the Harisson/Mixbus guys on Windows....)

Ok, great. Thanks for your help. Let me know anything comes up that I can
help with.

-- Basil

Basil Nutmeg added 3 commits April 2, 2013 15:52
The types int64_t, uint64_t, and double have different alignments
between common 32-bit and 64-bit platforms, and this can cause
trouble when they are used in structs which are shared between
address spaces. Introduce new typedefs for these types with
special alignment attributes to request consistent alignment.

ABI implications:

In the current tree, with packed attributes on the relevant structs,
the only impact of this change is that the alignments of jack_unique_t
and jack_time_t are increased from 4 to 8 on 32-bit platforms, so
the layouts of structs which include them as members may be affected.

The ABI impact relative to the tree before the packed attributes
were introduced is that the alignment of jack_position_t is increased
from 4 to 8 on 32-bit platforms. The layout of the struct itself is
unmodified, though the layouts of structs which include it as a
member may be affected.
Update internal types to have the same layout between 32-bit and
64-bit, using the new alignment macros and types.
Remove use of packed structs, now that the infrastructure for consistently
aligning types between 32-bit and 64-bit platforms is in place. This fixes
crashes on platforms which enforce alignment rules (because there are
places in the code where pointers to packed fields are used).

Also, it theoretically improves performance, though I haven't actually
performed any measurements.

ABI implications:

jack_latency_range_t and jack_position_t are no longer packed. The layouts
of these structs themselves are unmodified, though the layouts of any
structs which include these structs as members may be affected.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants