-
Notifications
You must be signed in to change notification settings - Fork 326
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
Prevent re-entrant execution of finalizers #10602
Conversation
engine/runtime/src/main/java/org/enso/interpreter/runtime/ResourceManager.java
Show resolved
Hide resolved
engine/runtime/src/main/java/org/enso/interpreter/runtime/ResourceManager.java
Outdated
Show resolved
Hide resolved
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 look at the scheduleFinalizationAtSafepoint
method and wonder - does it still do what it says? Looking at the code, the submitThreadLocal
call was removed from it. It seems that this method is now actually doing finalizeAndUnregisterFromList
or something like that, but not quite scheduleFinalizationAtSafepoint
.
Can we get the method name updated to reflect its current meaning? Otherwise it is just misleading
The Enso tests look good. Out of curiosity, how long does it take to allocate and clean the 100k resources? |
enso$ time ./built-distribution/enso-engine-0.0.0-dev-linux-amd64/e
nso-0.0.0-dev/bin/enso --run test/Base_Tests/src/Runtime/GC_Example.enso 100000
Allocating 100000 resources...
Cleaning up...
All cleaned up! Remaining: 0
0
real 0m6,252s
user 0m26,125s
sys 0m3,088s vs. enso$ time ./built-distribution/enso-engine-0.0.0-dev-linux-amd64/enso-0.0.0-dev/bin/enso --run test/Base_Tests/src/Runtime/GC_Example.enso 1
Allocating 1 resources...
Cleaning up...
All cleaned up! Remaining: 0
0
real 0m5,300s
user 0m18,851s
sys 0m2,424s |
Looks good but I think the |
Let's remove the method altogether. Then we don't need to care about naming: 0cc2288! |
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 for addressing the misleading method name, it looks better now.
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 don't understand the code entirely, but I trust the tests.
There is a test failure:
|
Related ticket: #10610 |
for (; ; ) { | ||
Item[] toProcess; | ||
synchronized (pendingItems) { | ||
request.cancel(false); |
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.
request
is guaranteed to be non-null at this point?
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.
It should be non-null
. To get into this process
method, a call to submitThreadLocal must be made and it assigns the request
.
The request
is only assigned back to null
in this method, just before return
- after this check.
E.g. unless there is some re-entrant invocation of the process
method (it was there, but I hopefully fixed it), request
shall not be null
at this point.
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.
Yes, I can see that gets set there along with adding to pendingItems
. But it wasn't obvious that perform
can't be called with an empty pendingItems
and then it would crash.
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.
Shall we maybe include an assert at least?
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.
What's a difference between NullPointerException
and AssertionError
?
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.
Usually the NPE can be delayed and happen somewhere down the line, making debugging harder.
In this case I guess you are right - no meaningful difference. I just don't like NPEs so that was by habit :)
… comparators than one
@@ -57,6 +58,10 @@ add_specs suite_builder = suite_builder.group "Managed_Resource" group_builder-> | |||
r_3 = Panic.recover Any <| Managed_Resource.bracket 42 (_-> Nothing) (_-> Panic.throw "action") | |||
r_3.catch . should_equal "action" | |||
|
|||
group_builder.specify "allocate lots of resources at once" <| |
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.
This test was disabled by
Attempt to diagnose what the problem was is at
it.flaggedForFinalization.set(true); | ||
synchronized (pendingItems) { | ||
if (request == null) { | ||
request = context.submitThreadLocal(null, this); |
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.
Here is the submitThreadLocal javadoc.
If the threads array is null then the thread local action will be performed on all alive threads
Right now, when we run single threaded, one thread will pick the action. In the future, multiple threads may execute the perform
method. In such situation the request may actually become null for some (slower) threads.
Using recurring events should be preferred
The ProcessItems
constructor marks the ThreadLocalAction
as recurring to make sure some thread will pick our action up.
ThreadLocalAction javadoc is also available.
Asynchronous thread-local actions might start and complete to perform independently of each other.
Yes, we want asynchronous action, as we only want to run the action on a single thread. We don't care about others.
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.
Continues at the next PR.
Pull Request Description
Fixes #10211 by avoiding re-entrant execution of finalizers.
Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:
Scala,
Java,