Dynamic setting of JPL_MAX_POOL_ENGINES

[ssardina]

Currently variable JPL_MAX_POOL_ENGINES in jpl.c defines the max number of Prolog engines available.

Would be good to be able to set this number when initializing the JNI.

[anionic]

Better still, let's allow this value to be changed freely, repeatedly, at any time, subject to sensible bounds. It can be reduced to no less than the qty of engines created so far, and increased without obvious limit. If JPL is already initialised, this will mean re-malloc-ing the array for the engine addresses; we already have a mutex for making this thread-safe. It seems unnecessarily burdensome on users to force anyone needing extra engines to request them before JPL inits, as it could have been initialised as a side-effect of an unrelated JPL call.
Also I suggest we design a Java API for getting and (where feasible) setting named internal JPL parameters and metrics, then we can extend this, rather like xxx_prolog_flag/2. we'll have to deal with String and int/long params :-/ and offer a corresponding Prolog API.

[ssardina]

Better still, let's allow this value to be changed freely, repeatedly, at any time, subject to sensible bounds. It can be reduced to no less than the qty of engines created so far, and increased without obvious limit. If JPL is already initialised, this will mean re-malloc-ing the array for the engine addresses; we already have a mutex for making this thread-safe. It seems unnecessarily burdensome on users to force anyone needing extra engines to request them before JPL inits, as it could have been initialised as a side-effect of an unrelated JPL call.

I like it, yes much nicer.

Also I suggest we design a Java API for getting and (where feasible) setting named internal JPL parameters and metrics, then we can extend this, rather like xxx_prolog_flag/2. we'll have to deal with String and int/long params :-/ and offer a corresponding Prolog API.

I think I got the first part, but not the latter one in bold. What parameters and metrics for example would be good to set? I guess you mean build both Java API and Prolog API to get and set those parameters of interest. The only one I thought now is the number of engines. Which others would be useful to have a grab?

[anionic]

I don't want a case-by-case argument ;-) I just think it's wise practice to make this new API open-ended. A nice example would be: the next compiled-in limit which you wish to change ;-) Also there are various caching policies which could be set on or off, and various statistics e.g. cache sizes, qtys of calls made. The only argument I see against this is the Java-side complication of getting/setting a mix of string, bool and int values: either we box them, or have e.g.

String currentJplStringFlag(String key)
long currentPrologLongFlag(String key)
void setJplStringFlag(String key, String value)
void setJplLongFlag(String key, long value)

adapting the precedent of current_prolog_flag/2 etc.
But maybe this is a generality too far? I'm not entirely sure...

[ssardina]

Not sure I am following but my understanding is that you would like to "lift" many of the hard-coded parameters of the C side of JPL to configurable from Java/SWI. Is this correct?

[anionic]

Yes in principle; I thought that while we (you!) are doing this, it would be good to anticipate any other possible limit-raising requests by intensive users, but glancing through jpl.c I can't see any :-/ so maybe we just keep this simple? The various caches I alluded to are entirely within Prolog, and the "hr" hashtable stuff 1) already has API to report its stats and 2) is probably redundant anyway ;-)