-
Notifications
You must be signed in to change notification settings - Fork 141
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
Improve memory-safety of Semigroup instances #443
Conversation
Is it possible to add regression tests? At least for 32-bit platforms. |
To some extent, sure. I could evaluate and catch expected-exceptions from (potentially-tricky) overflow-nonsense-values inside an IO property. That seems a bit strange, though. Is there a more natural approach for this that I'm ignorant of? Should I write some? |
@clyring yes, via prop = ioProperty $ do
t <- try (evaluate foo)
pure $ isLeft t |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for delay, been busy with 0.11.2.0 release.
Looking at the Core, it seems the rewrite rules on |
I've reported the build failure with 9.2.1 at GHC's issue tracker. |
@clyring any plans to resume the work here? |
I'll try to rebase and clean up a bit more tomorrow. |
Some nearby low-hanging fruit are also gathered.
The 'timesInt2#' primop just doesn't exist before 9.0.1.
This causes GHC 9.2.1 to panic, for reasons I do not understand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty confused about the motivation for all these changes.
I think it would be best if you'd open proper bug reports on the issue tracker that you can reference from commit messages and comments.
I also think that this PR is getting a bit too large to review easily. If it gets any larger, maybe split it into one PR per instance. |
When I opened this pull request, there was one commit making a large handful of near-trivial changes, for which a separate issue would hardly be smaller than the patch, whose motivation is adequately summarized by its commit title. But inject tests and a desire to not allocate
I agree that this PR is getting a bit large. It's already only substantially touching one instance; if the current insubstantial tweaks to the others are too distracting I can bundle them with a later PR. |
I do think that a bug report would be very helpful. Memory safety isn't a topic that I'm encountering very frequently in Haskell code. I hope a bug report would make it clear what precisely the problem with the current code is. This will also be useful for communicating this change to To simplify the review, I think having one PR per instance would be easiest. |
Apologies for my inactivity on this PR. Unfortunately my understanding of the problem that this PR is intended to solve is still very fuzzy. I'd like to know:
@clyring Could you please write this up on the issue tracker? I think a clearer exposition of the problem will motivate us to find a solution and help guide us to the right trade-off between memory safety, performance and code complexity. For now I have two ideas for reducing complexity:
Once we have a clearer understanding of the problem we can discuss whether and where these measures might make sense. |
The merge conflicts were trivial; I have resolved them.
This already exists an issue on the tracker for this: #456
I'm somewhat unhappy with the current implementation's need for ugly inline hacks and the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding the perf issues, my suggestion is to wait and see whether the WIP improvements in GHC (https://gitlab.haskell.org/ghc/ghc/-/issues/20361) will take care of this. We can record a reminder on our issue tracker.
Its ByteString argument is also marked as strict. This doesn't change the optimized code produced by GHC, but allows it to be consistent with the published imprecise exception semantics.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Amusingly, the intermediate- |
Thanks @clyring! |
I have opened #493 as a reminder. |
After making this comment, I was a bit disappointed to discover that the existing
Semigroup
instances forStrictByteString
andShortByteString
were also memory-unsafe in the presence ofInt
overflow. Here's a quick pass adding some overflow checks where they are necessary, along with a couple of other related small improvements.