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.

Sign up for GitHub

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

refactor: no-ticket: make DeferredColumnRegionBase more efficient wrt volatile #6574

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

refactor: no-ticket: make DeferredColumnRegionBase more efficient wrt volatile #6574

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 10 additions & 17 deletions ...c/main/java/io/deephaven/engine/table/impl/sources/regioned/DeferredColumnRegionBase.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,6 @@

import io.deephaven.base.verify.Require;
import io.deephaven.chunk.attributes.Any;
import io.deephaven.engine.table.SharedContext;
import io.deephaven.chunk.*;
import io.deephaven.engine.rowset.RowSequence;
import org.jetbrains.annotations.NotNull;
Expand Down Expand Up @@ -33,39 +32,33 @@ public abstract class DeferredColumnRegionBase<ATTR extends Any, REGION_TYPE ext
public void invalidate() {
super.invalidate();
synchronized (this) {
if (resultRegion != null) {
resultRegion.invalidate();
REGION_TYPE localResultRegion;
Copy link
Member

Choose a reason for hiding this comment

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

I don't think this case actually needs a lock as written. But maybe we should keep is this way and null out the result region after invalidating?

Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure about this.

  • Keeping a non-null, invalidated result in place makes the invalidation sticky.
  • getResultRegion() isn't checking if we're invalidated, so if we were to null out the result we might create a new one. But that could also happen if invalidate() were to be called before the first call to getResultRegion().

Copy link
Member Author

Choose a reason for hiding this comment

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

I didn't try to dig any deeper into the intentions. As my PR stands, it's a pure refactor that preserves the existing behavior.

if ((localResultRegion = resultRegion) != null) {
localResultRegion.invalidate();
}
}
}

@Override
public final REGION_TYPE getResultRegion() {
if (resultRegion == null) {
REGION_TYPE localResultRegion;
if ((localResultRegion = resultRegion) == null) {
synchronized (this) {
if (resultRegion == null) {
resultRegion = Require.neqNull(resultRegionFactory.get(), "resultRegionFactory.get()");
if ((localResultRegion = resultRegion) == null) {
resultRegion =
localResultRegion = Require.neqNull(resultRegionFactory.get(), "resultRegionFactory.get()");
resultRegionFactory = null;
}
}
}
return resultRegion;
}

/**
* Get the result region if it has already been supplied (because of a call to {@link #getResultRegion()}).
*
* @return The result region
*/
private REGION_TYPE getResultRegionIfSupplied() {
return resultRegion;
return localResultRegion;
}

@Override
@OverridingMethodsMustInvokeSuper
public void releaseCachedResources() {
DeferredColumnRegion.super.releaseCachedResources();
final REGION_TYPE localResultRegion = getResultRegionIfSupplied();
final REGION_TYPE localResultRegion = resultRegion;
if (localResultRegion != null) {
localResultRegion.releaseCachedResources();
}
Expand Down