RVM

Finish removing all uses of LogicallyUninterruptible

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: 3.1.4
  • Component/s: Runtime
  • Labels:
    None
  • Number of attachments :
    0

Description

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.

Issue Links

is depended upon by

Sub-task - The sub-task of the issue RVM-228 Turn off bounds checks and null checks in uninterruptible code

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Task - A task that needs to be done. RVM-222 Reduce bootimage bloat

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Open - The issue is open and ready for the assignee to start work on it.
is duplicated by

Bug - A problem which impairs or prevents the functions of the product. RVM-598 Increase use of unpreemptible

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ian Rogers added a comment -

Most cases where unpreemptible is suitable are currently marked logically uninterruptible.

Show
Ian Rogers added a comment - Most cases where unpreemptible is suitable are currently marked logically uninterruptible.
Hide
Permalink
Ian Rogers added a comment -

Most of the work of this is done by RVM-598. The remaining cases should be tidied up for 3.0.

Show
Ian Rogers added a comment - Most of the work of this is done by RVM-598 . The remaining cases should be tidied up for 3.0.
Hide
Permalink
Ian Rogers added a comment -

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.

Show
Ian Rogers added a comment - 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.
Hide
Permalink
Ian Rogers added a comment -

This is fixed in the RVM in r14800, r14791 and r14789. Logically uninterruptible still needs removing from MMTk, see the comment above.

Show
Ian Rogers added a comment - This is fixed in the RVM in r14800, r14791 and r14789. Logically uninterruptible still needs removing from MMTk, see the comment above.
Hide
Permalink
David Grove added a comment -

Defer to 3.1.1

Show
David Grove added a comment - Defer to 3.1.1
Hide
Permalink
David Grove added a comment -

bulk defer open issues to 3.1.2

Show
David Grove added a comment - bulk defer open issues to 3.1.2
Hide
Permalink
David Grove added a comment -

bulk defer to 3.1.4

Show
David Grove added a comment - bulk defer to 3.1.4

People

  • Assignee:
    Daniel Frampton
    Reporter:
    David Grove
Vote (0)
Watch (1)

Dates

  • Created:
    Updated: