Issue Details (XML | Word | Printable)

Key: RVM-115
Type: Improvement Improvement
Status: Open Open
Priority: Minor Minor
Assignee: Daniel Frampton
Reporter: David Grove
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
RVM

Finish removing all uses of LogicallyUninterruptible

Created: 05/Jul/07 12:06 PM   Updated: 14/Oct/08 07:57 AM
Component/s: Runtime
Affects Version/s: None
Fix Version/s: 3.0.2

Time Tracking:
Not Specified

Issue Links:
Duplicate
 
dependent
 


 Description  « Hide
Several years ago Perry, Daniel, and I started removing uses of LogicallyUninterruptible and replacing them with UninterruptibleNoWarn or Unpremptible (depending on the actual semantics of each usage...).

We should finish this work item and finally kill LogicallyUninterruptible.

In addition to being cleaner, this change could also allow us to do further optimization of uninterruptible code (for example since uninteruptible code is not allowed to raise exceptions (NullPointer, ArrayBoundsCheck), we could in principle compile uninterruptible code without nullcheck/boundcheck operations. Whether or not this is actually a good idea is less clear, but it isn't even possible to safely try this until we do the cleanups and make Uninterruptibility a strictly enforced property with fewer loopholes.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Ian Rogers added a comment - 24/Jul/08 10:50 AM
Most cases where unpreemptible is suitable are currently marked logically uninterruptible.

Ian Rogers added a comment - 24/Jul/08 10:52 AM
Most of the work of this is done by RVM-598. The remaining cases should be tidied up for 3.0.

Ian Rogers added a comment - 25/Jul/08 02:19 PM
In Space.acquire (which is an uninterruptible class):

public final Address acquire(int pages) {
boolean allowPoll = !Plan.gcInProgress() && Plan.isInitialized() && !VM.collection.isEmergencyAllocation();

/* First check page budget and poll if necessary */
if (!pr.reservePages(pages)) {
/* Need to poll, either fixing budget or requiring GC */
if (allowPoll && VM.activePlan.global().poll(false, this)) { pr.clearRequest(pages); return Address.zero(); // GC required, return failure }
}

the call to poll may context switch, as this breaks the uninterruptible guarantee poll is annotated LogicallyUninterruptible. Having uninterruptible code that can switch context is invalid, instead the code should be annotated Unpreemptible (a weaker guarantee that the compiler won't place implicit scheduling code into the JIT generated code). To get rid of the LogicallyUninterruptible and clean up this code there are 2 solutions:

1) mark Space.acquire as unpreemptible and then mark every uninterruptible MMTk routine that calls it unpreemptible. This is undesirable as it means we mark collector phases as unpreemptible, whereas they do satisfy uninterruptibility and we should enforce this.

2) create an uninterruptible version of Space.acquire and anything that calls it, mark Space.acquire and anything that calls it unpreemptible. In the collector phases use uninterruptible versions of the code.

I believe 2 is the way we should solve this problem but does mean a fairly large change to MMTk. If I can get a quick response we can make it into 3.0.


Ian Rogers added a comment - 25/Jul/08 05:33 PM
This is fixed in the RVM in r14800, r14791 and r14789. Logically uninterruptible still needs removing from MMTk, see the comment above.