Skip to content

Detect double destruction and generalize $createDestroyFunction#760

Merged
ktoso merged 2 commits into
swiftlang:mainfrom
sidepelican:free_check
May 20, 2026
Merged

Detect double destruction and generalize $createDestroyFunction#760
ktoso merged 2 commits into
swiftlang:mainfrom
sidepelican:free_check

Conversation

@sidepelican
Copy link
Copy Markdown
Contributor

This PR introduces two improvements to the destruction process of Swift instances.

1. Detect double destruction

Currently, if a double destruction occurs due to an implementation error, the process simply crashes without any diagnostics.
To throw an error, this PR passes the statusDestroyedFlag directly to the cleanup instance instead of markAsDestroyed.

2. Generalize $createDestroyFunction

Previously, a unique destroy function was generated for each individual class.
However, we have transitioned to a shared invocation of SwiftObjects.destroy (in #582 ).
Since there is no longer a reason to generate a separate $createDestroyFunction implementation for every single class, this PR provides a default implementation to minimize the footprint of the generated code.

Note: Unlike the FFM side, $createDestroyFunction is still required here because certain classes still implement their own custom destroy logic.

@sidepelican sidepelican requested a review from ktoso as a code owner May 20, 2026 03:44
@sidepelican
Copy link
Copy Markdown
Contributor Author

Gradle seems unhealthy again today 🤒

@ktoso
Copy link
Copy Markdown
Collaborator

ktoso commented May 20, 2026

Yeah that's what we get for running 60 jobs... I'll work on getting less jobs to run soon; but we'll have to cut coverage of swift versions etc. At least less flaky fails then

private final MemorySegment memoryAddress;
private final SwiftAnyType type;
private final Runnable markAsDestroyed;
private final AtomicBoolean statusDestroyedFlag;
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could move to atomic field updater here, but I'm happy to do this separately

@ktoso ktoso merged commit 899c7b4 into swiftlang:main May 20, 2026
145 of 146 checks passed
@sidepelican sidepelican deleted the free_check branch May 20, 2026 07:14
ktoso added a commit to ktoso/swift-java that referenced this pull request May 20, 2026
We can use an atomic field updater and avoid the AtomicBoolean
allocation this way.

This keeps semantics added by @sidepelican in
swiftlang#760 just avoids the one
heap alloc per SwiftInstance
ktoso added a commit to ktoso/swift-java that referenced this pull request May 20, 2026
The atomic boolean was one extra heap allocation which we now avoid --
we just create one cleanup and inside it have an int, rather than
creating the Bool separately and passing it to the cleanup. AFAICS this
will avoid one alloc, which isn't much, but can add up since we do it
for every wrapped swift object.

This keeps semantics added by @sidepelican in
swiftlang#760 just avoids the one
heap alloc per SwiftInstance
ktoso added a commit that referenced this pull request May 20, 2026
…761)

The atomic boolean was one extra heap allocation which we now avoid --
we just create one cleanup and inside it have an int, rather than
creating the Bool separately and passing it to the cleanup. AFAICS this
will avoid one alloc, which isn't much, but can add up since we do it
for every wrapped swift object.

This keeps semantics added by @sidepelican in
#760 just avoids the one
heap alloc per SwiftInstance
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