Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use specially-aligned types instead of packed structs #1

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

basilnut
Copy link

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
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
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
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
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