Adding a field to StrongRefCount class

Hi,

I want to add a field to StrongRefCount class for some experiment, but the
build fails while building self-hosted 'swift-build'. I am using the
version 3.1.1.

Does the shape of StrongRefCount class have any implicit dependence on
other parts of the runtime? What is the correct way to add a field to this
class?

Thanks,
Jiho

I want to add a field to StrongRefCount class for some experiment, but the build fails while building self-hosted 'swift-build'. I am using the version 3.1.1.

Does the shape of StrongRefCount class have any implicit dependence on other parts of the runtime?

The size of the heap header is hard-coded in the compiler. There's a function getHeapHeaderSize in StructLayout.cpp, but you'll also need to update the definition of RefCountedStructTy in IRGenModule.cpp, and almost certainly some other places. It's not something that's been carefully abstracted because it's something we don't really expect to change.

John.

···

On Sep 26, 2017, at 12:56 AM, Jiho Choi via swift-dev <swift-dev@swift.org> wrote:

What is the correct way to add a field to this class?

Thanks,
Jiho
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Thanks for the explanation. I modified those two locations you mentioned
but the build failed during tests. I've been browsing the source code to
figure out other dependences but didn't succeed yet. Could you please give
me some pointers on where to look at?

Regards,
Jiho

···

On Tue, Sep 26, 2017 at 12:22 AM John McCall <rjmccall@apple.com> wrote:

> On Sep 26, 2017, at 12:56 AM, Jiho Choi via swift-dev < > swift-dev@swift.org> wrote:
> I want to add a field to StrongRefCount class for some experiment, but
the build fails while building self-hosted 'swift-build'. I am using the
version 3.1.1.
>
> Does the shape of StrongRefCount class have any implicit dependence on
other parts of the runtime?

The size of the heap header is hard-coded in the compiler. There's a
function getHeapHeaderSize in StructLayout.cpp, but you'll also need to
update the definition of RefCountedStructTy in IRGenModule.cpp, and almost
certainly some other places. It's not something that's been carefully
abstracted because it's something we don't really expect to change.

John.

> What is the correct way to add a field to this class?
>
> Thanks,
> Jiho
> _______________________________________________
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

Thanks for the explanation. I modified those two locations you mentioned but the build failed during tests. I've been browsing the source code to figure out other dependences but didn't succeed yet. Could you please give me some pointers on where to look at?

You'll have to look at the test failures individually. If they're just IRGen tests failing because the IR no longer matches the current output, then you need to either fix the tests or just ignore them for the purposes of your experiment. If they're IRGen tests failing because the compiler is crashing, or execution tests failing because the running code is crashing, it's likely that I just forgot something that depends on the output. We're not going to be able to debug this problem for you in the abstract, though.

John.

···

On Sep 27, 2017, at 1:24 PM, Jiho Choi <jray319@gmail.com> wrote:

Regards,
Jiho

On Tue, Sep 26, 2017 at 12:22 AM John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:
> On Sep 26, 2017, at 12:56 AM, Jiho Choi via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
> I want to add a field to StrongRefCount class for some experiment, but the build fails while building self-hosted 'swift-build'. I am using the version 3.1.1.
>
> Does the shape of StrongRefCount class have any implicit dependence on other parts of the runtime?

The size of the heap header is hard-coded in the compiler. There's a function getHeapHeaderSize in StructLayout.cpp, but you'll also need to update the definition of RefCountedStructTy in IRGenModule.cpp, and almost certainly some other places. It's not something that's been carefully abstracted because it's something we don't really expect to change.

John.

> What is the correct way to add a field to this class?
>
> Thanks,
> Jiho
> _______________________________________________
> swift-dev mailing list
> swift-dev@swift.org <mailto:swift-dev@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-dev

You should look at pull requests #7837 and #9214:

#7837 the object header size on 32-bit architectures. The PR is not currently up-to-date, but should give you an idea of the scope of changes that would be necessary for your experiment. #9214 is an addition after #7837 that would also be affected by a header size change.

Another approach for experimental purposes is to modify StrongRefCount without changing its size. That struct is designed to store some data inline, and if necessary can transform into an out-of-line form that stores data of any size.

You could change the arrangement of bits in the StrongRefCount inline form if you only need a few bits for your storage.

Or you could force StrongRefCount to always use the out-of-line form and store whatever data you want there. This would be slower but probably fine for experimentation.

···

On Sep 27, 2017, at 10:39 AM, John McCall via swift-dev <swift-dev@swift.org> wrote:

On Sep 27, 2017, at 1:24 PM, Jiho Choi <jray319@gmail.com <mailto:jray319@gmail.com>> wrote:

Thanks for the explanation. I modified those two locations you mentioned but the build failed during tests. I've been browsing the source code to figure out other dependences but didn't succeed yet. Could you please give me some pointers on where to look at?

You'll have to look at the test failures individually. If they're just IRGen tests failing because the IR no longer matches the current output, then you need to either fix the tests or just ignore them for the purposes of your experiment. If they're IRGen tests failing because the compiler is crashing, or execution tests failing because the running code is crashing, it's likely that I just forgot something that depends on the output. We're not going to be able to debug this problem for you in the abstract, though.

--
Greg Parker gparker@apple.com <mailto:gparker@apple.com> Runtime Wrangler

Now I am finally able to build the Swift runtime with an extended object
header and run some benchmarks. For future reference, in addition to
making changes similar to the commits which Greg pointed to, I needed to
change the Foundation library's CFRuntimeBase class which mirrors the
Swift's object header layout.

···

On Thu, Sep 28, 2017 at 11:52 PM Greg Parker <gparker@apple.com> wrote:

On Sep 27, 2017, at 10:39 AM, John McCall via swift-dev < > swift-dev@swift.org> wrote:

On Sep 27, 2017, at 1:24 PM, Jiho Choi <jray319@gmail.com> wrote:

Thanks for the explanation. I modified those two locations you mentioned
but the build failed during tests. I've been browsing the source code to
figure out other dependences but didn't succeed yet. Could you please give
me some pointers on where to look at?

You'll have to look at the test failures individually. If they're just
IRGen tests failing because the IR no longer matches the current output,
then you need to either fix the tests or just ignore them for the purposes
of your experiment. If they're IRGen tests failing because the compiler is
crashing, or execution tests failing because the running code is crashing,
it's likely that I just forgot something that depends on the output. We're
not going to be able to debug this problem for you in the abstract, though.

You should look at pull requests #7837 and #9214:
WIP: [IRGen][runtime] Reduce object header to 8 bytes on 32-bit platforms. by gparker42 · Pull Request #7837 · apple/swift · GitHub
Support key paths on 32-bit platforms. by jckarter · Pull Request #9214 · apple/swift · GitHub

#7837 the object header size on 32-bit architectures. The PR is not
currently up-to-date, but should give you an idea of the scope of changes
that would be necessary for your experiment. #9214 is an addition after
#7837 that would also be affected by a header size change.

Another approach for experimental purposes is to modify StrongRefCount
without changing its size. That struct is designed to store some data
inline, and if necessary can transform into an out-of-line form that stores
data of any size.

You could change the arrangement of bits in the StrongRefCount inline form
if you only need a few bits for your storage.

Or you could force StrongRefCount to always use the out-of-line form and
store whatever data you want there. This would be slower but probably fine
for experimentation.

--
Greg Parker gparker@apple.com Runtime Wrangler