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

Using onheap keyword in concurrent classes #1714

Merged
merged 1 commit into from
May 13, 2016

Conversation

marcusnaslund
Copy link
Contributor

@marcusnaslund marcusnaslund commented May 12, 2016

This is better than creating a new Cell instance every time (which also leaks in certain circumstances, as memchecking the tests show).

This PR fixes all (yay!) memory leaks in concurrent tests as part of #1699 together with #1712

Will have to be tested thoroughly.

@@ -109,7 +109,7 @@ Future: abstract class <T> {
}

_ThreadFuture: class <T> extends Future<T> {
_result: Object
_result: __onheap__ T
Copy link

Choose a reason for hiding this comment

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

And just when I thought ooc code can't get more confusing than it already is... Is inline assembly the next step ? :P

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is actually exactly the keyword that Cell uses to make sure its contents doesn't disappear in a long lost stack frame.
We should really change the keyword to something prettier, though.

Copy link

Choose a reason for hiding this comment

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

keyword that Cell uses

Yeah, and it's slowly making it's way to higher level classes :)

Choose a reason for hiding this comment

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

I've pointed out on rock#48 that this could be automatically done by the compiler, would be happy to oblige if you think it's worth it now that it isn't used in many places.

(So I can remove the keyword from the language too at the same time now that it's only used in a couple of places)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nice, I hadn't seen that. I would certainly prefer to not have to manually add this keyword, but I will need to look into it some more. @thomasfanell and @fredrikbryntesson , thoughts?

Copy link

Choose a reason for hiding this comment

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

Thanks, I think we should be less explicit about memory management if we can.
I'd love to see this done automatically, but I think @thomasfanell or @fredrikbryntesson should be the one to decide.

@marcusnaslund marcusnaslund force-pushed the concurrentonheap branch 2 times, most recently from 59b0724 to 83dec62 Compare May 12, 2016 08:17
@@ -65,6 +65,8 @@ ThreadPoolTest: class extends Fixture {
comparison := t"fail"
result := future wait(comparison)
expect(result == comparison)
Time sleepMilli(1000)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

We can currently not wait on a Future we have previously called cancel on. This is ugly but works for now. We will get something better with #1588 or similar.

@thomasfanell
Copy link
Contributor

Obviously, if we could have rock generate the equivalent of __onheap__ and it is reliable, we should definitely do it.

@marcusnaslund
Copy link
Contributor Author

Peer review @sebastianbaginski ?

@ghost ghost added ready and removed peer review labels May 12, 2016
@marcusnaslund
Copy link
Contributor Author

👍 Will be doing some stress tests before I merge this.

@marcusnaslund
Copy link
Contributor Author

Works like a charm.

@marcusnaslund marcusnaslund merged commit 6823437 into magic-lang:develop May 13, 2016
@marcusnaslund marcusnaslund deleted the concurrentonheap branch May 26, 2016 13:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants