Compile charm with CMK_LBDB_ON=0

[ritvikrao]

This allows Charm++ to compile with CMK_LBDB_ON set to off.

[lvkale]

It will be worthwhile to run some fine grained benchmarks with and without this being set to 1. (make sure you are timing inside the program.. not the startup.) . For pingpong with chare arrays, use a long number of iterations. You also may need a program with UsesAtSync (?) and isMigratable turned on, which is nevertheless fine grained. Of course without any actual calls to AtSync().

[lvkale]

I will approve it soon, since we need it merged but:
(a) we should write the performance test I indicated. Although admittedly is tedious to run the test since w need two different bulds of charm (without and without CMK_LBDB_ON).
(b) is this meant to shut of only object load measurement or object migration itself? If only the former, we still need location record (right?) . This is when (for exmple) you may use migrteMe() calls, or balance based on estimated loads, or migrate for other objectives than load balancing (such as shrink expand or fault tolerance).

[Copilot]

Pull Request Overview

This PR enables Charm++ to compile with the CMK_LBDB_ON flag set to off by reorganizing conditional compilation blocks and moving some declarations outside of LBDB-specific guards.

• Reorganizes conditional compilation blocks to ensure necessary declarations are available regardless of LBDB status
• Moves critical member variables and function declarations outside of CMK_LBDB_ON guards
• Adds default parameter to ckFinishConstruction method

Reviewed Changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/ck-ldb/LBObj.C	Reorganizes CMK_LBDB_ON guards to allow IncrementTime method to compile without LBDB
src/ck-core/ckmigratable.h	Adds default parameter to ckFinishConstruction method
src/ck-core/cklocrec.h	Moves syncBarrier and ldHandle declarations outside CMK_LBDB_ON guards
src/ck-core/ck.h	Removes CMK_LBDB_ON guard from CkActiveLocRec function declaration
src/ck-core/ck.C	Moves CMK_LBDB_ON guard inside CkActiveLocRec function implementation

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The function CkActiveLocRec has no return statement when CMK_LBDB_ON is disabled, which will cause undefined behavior. Add an explicit return statement for the disabled case, such as return nullptr; after the #endif.

Suggested change

	#endif
	#endif
	return nullptr;

[ritvikrao]

I will approve it soon, since we need it merged but: (a) we should write the performance test I indicated. Although admittedly is tedious to run the test since w need two different bulds of charm (without and without CMK_LBDB_ON). (b) is this meant to shut of only object load measurement or object migration itself? If only the former, we still need location record (right?) . This is when (for exmple) you may use migrteMe() calls, or balance based on estimated loads, or migrate for other objectives than load balancing (such as shrink expand or fault tolerance).

a ) I will work on it. But what's interesting is that you can just turn the instrumentation off with +LBOff at runtime. The CMK_LBDB_ON option seems to be a legacy of when LBDatabase was also responsible for load balancing management. But PR #2530 from 2020 created a separate LBManager that is always on, with object statistics able to be turned off at runtime (and then optionally turned on manually in the code with LBTurnInstrumentOn().
b) that's a good catch, I changed the build to allow the location record to be retrieved at all times. CMK_LBDB_ON just enables/disables the load balancing database (the stats collection and timing)