search

SWI-Prolog / packages-jpl

JPL: The Prolog <-> Java interface
BSD 2-Clause "Simplified" License
54 stars 33 forks source link

Dynamic setting of JPL_MAX_POOL_ENGINES #25

Open ssardina opened 5 years ago

ssardina commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 ;-)