I should have said 'the J symbol AREA is a contiguous array...' The
symbol tables are separate structures (closed-address hashtables whose
chains are symbols from the J symbol area).
I do allocate symbols for the known named variables when an explicit
definition is first scanned. But:
* names can be synthetic, so there's no way to guarantee that symbols
are available
* when a definition is recursive, it needs to get a new set of symbols
for each level
So: yes, creating any symbol, local or global, may relocate all symbols
everywhere. Should I have said DEPRECATED!!!?
'Managing' the risk that another thread will delete your symbol is
possible only if you can control everything that is executing. Otherwise
you're whistling past the graveyard when you use a pointer to a block
that may have been relocated.
Henry Rich
On 4/4/2022 8:21 PM, Raul Miller wrote:
On Mon, Apr 4, 2022 at 7:55 PM Henry Rich <[email protected]> wrote:
Accessing the symbol table is deprecated. Don't do it.
That sounds like solid advice.
And, I am going to quote your final advice, up front, to avoid too
much distraction from my upcoming question:
WHAT YOU NEED TO DO is use 15!:14 if you want the address of the first
atom, or 15!:12 (new in J9.04) to get the address of the header. The
header and data will not be relocated.
There's some behind the scenes concepts here that are probably worth
understanding. But, for most purposes, this much is probably
sufficient.
That said...
The J symbol table is a contiguous array of structures that connect
names and values. When the table fills, a larger one is allocated and
the symbols are all relocated. The table may become full any time a new
symbol is created.
Thus, your very first line
s=. symget <y
is not robust. symget will return a pointer (as an integer), but the
assignment to s may relocate the symbol table, which means that your
pointer may be invalid before you even store it into s.
There is no way around this, and the problem applies to all releases of JE.
Is that really an issue here? In other words, would allocating a local
symbol update the global symbol table?
(If it was, it seems like pre-allocating all symbols that your routine
would use before referencing the symbol table would work around that
issue.)
If that's not bad enough, a routine you call, or a J task running in a
thread, may delete any global name and leave you with an invalid pointer.
Definitely a risk. One that would have to be managed.
WHAT YOU NEED TO DO is use 15!:14 if you want the address of the first
atom, or 15!:12 (new in J9.04) to get the address of the header. The
header and data will not be relocated.
Thanks,
--
Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
