FWD » Core Development » Base Language

1. a shared-var leak for persistent procedures (they are not being removed when the persistent procedure gets deleted)
2. in case when prog A is ran persistent and a RUN proc0 IN prog-A-handle runs another program B which uses a new shared var defined by A, program B doesn't see the shared vars defined by A. I think this translates into something like 'SOURCE-PROCEDURE's shared context must be pushed to the stack before invoking something'.

The fixes are in 3394a rev 11225

In the end, the problem was that the lookup for shared vars must be performed on the entire stack of external programs, not just in the current one.

Code Review Task Branch 3394a Revision 11225

1. In ProcedureManager.searchInStack(), why use a map as searched instead of a set?

2. What is the reason behind the change in SVM.scopeDeleted() to return immediately if referent is THIS-PROCEDURE?

Greg Shah wrote:

Code Review Task Branch 3394a Revision 11225

1. In ProcedureManager.searchInStack(), why use a map as searched instead of a set?

Because I wanted to avoid the equality comparison in normal Java sets... it should be faster using identity comparison instead of equals.

2. What is the reason behind the change in SVM.scopeDeleted() to return immediately if referent is THIS-PROCEDURE?

The test is needed for cases when an internal procedure is ran inside the current context (i.e. without persistent support); scopeDeleted notifications are received for every scope, so this will not allow the state to be deleted. But actually, the code should have been referent == ProcedureManager._thisProcedure() && !TransactionManager.isExternalBlock() because otherwise non-persistent external proc state was not cleaned (I got a OOME in MAJIC testing).