Some time ago, Elijah Stone pointed out that using https://gmplib.org/manual/Low_002dlevel-Functions we could use J's memory management routines directly, without having to deal with libgmp's "exit the program if the library can't allocate memory" behavior.
This seems like it would be a good thing for us. When completed, we could eliminate the memory pool currently used when handling extended values, and we could also relax the current limit placed on the magnitude of extended values. But changing everything all at once is a good way to never get started. So, it's worth thinking about how we could organize this kind of effort. Currently, the code is partitioned in three chunks: libgmp itself (or mpir on windows), the jgmp.h/jgmpinit.h glue, and macros defined in jgmp.h which are used in most of the rest of the system. (There's also a few direct calls to libgmp functions in k.c, v2.c, vq.c, vx.c and wn.c) So, conceptually speaking, we could implement workalikes for these macros (things like XaddXX() which rely on the lower level mpn_ functions instead of the problematic mpz_ / mpq_ functions. (We could replace the direct calls with suitable macros, along the way. (Or, if there's cases where there's really a significant performance advantage, we could replace them with suitable direct calls to the memory management routines and mpn_ functions. But this seems unlikely.)) The trick would be allowing XNUM and RAT values whose memory was allocated via libgmp to coexist with XNUM and RAT values whose memory was allocated using J's memory manager. The details here are a bit annoying, but fundamentally we've already provided for this. Basically, the distinction matters when we free the memory. And, that decision is based on FHRHISGMP==AFHRH(x) vs FHRHISGMP!=AFHRH(x) in jgmp.h and jgmpinit.c ----------------------------------------------- So.. it seems to me that if we created a parallel glue rig -- maybe jgmpn.h -- we could start migrating functionality to the mpn_* family of functions and J's "native" memory management. XaddXX() seems like the place to start. I would need to figure out how to deal with the "realloc" cases where the amount of memory required for a calculation (like multiply or format) might be larger or smaller - perhaps significantly larger - than the memory needed to represent the result. But, once started, the work could proceed gradually. As long as the primitives continue to function, users mostly wouldn't notice the changes. (And, ok, that sounds discouraging. But hopefully the end result would be worth it.) Thoughts? My thought is that this kind of code cleanup seems worthwhile. Thanks, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
