:immediate sub cannot load_bytecode

[jkeenan]

When  RT #60000 was closed, chromatic indicated there would probably be a better way of accomplishing its aim.

"It's actually IMCC_INFO(interp)->ghash. In particular, constant folding assigns register numbers to constant PMCs and STRINGs as addresses into the constant table. That's good.

"Those constants are still around for code loaded from :immediate subs. That's also good.

"The problem is that the SymReg structures which represent those constants keep their assigned register numbers. That's bad, because they only get added to the bytecode if they don't already have register numbers representing indices into the constant table.

"Thus, they don't get assigned. This is a problem when handling parameters or return values. The PCC section of IMCC creates a FixedIntegerArray to handle these arguments, and that's a constant PMC in the bytecode. If this doesn't get created somehow (in the case I just described), other parts of the PCC-handling code expect it's there and throw an assertion if it isn't.

"The right fix is to walk IMCC_INFO(interp)->ghash and reset the color of all constant SymRegs to -1 before running any pragma subs (e_pbc_end_sub() in compilers/imcc/pbc.c), but r32633 is a quicker workaround for now, to get this closed. I'll work on the prettier fix in the next couple of days, unless someone beats me to it."

This needs to be followed in Trac.

[coke]

It would be very helpful if we had some instructions (i.e. code) that tickled this bug.

[whiteknight]

Immediate subs are executed as soon as they are compiled, as the compilation continues. This is part of what might be causing problems, because IMCC is terrible with respect to global state and reentrancy. Instead, if we change it so that we execute all immediate subs after compilation completes, but before IMCC returns the packfile to Parrot, it seems to have an almost identical effect (no tests fail) and I suspect that the issues mentioned in this ticket go away because we don't recursively enter a compilation or load.

in the whiteknight/pbc_pbc branch I have committed a "fix" to make :immediate subs execute after compilation, not during it. As I mentioned above, no tests fail with this change. This could mean that either it is not an important change, or it may mean that this particular behavior is not well exercised in our test suite. We may need two things:

• A test or tests to expose the bug discussed in this ticket, if it can still be reproduced.
• A test or tests to show that the new behavior of :immediate in the branch does or does not cause problems.

[whiteknight]

As an additional note, I am trying to deprecate PackFile_fixup_subs and remove it. IMCC relies on this function for executing :immediate and :postcomp subs. Once I figure out where this function is needed and how we rely on it, I can make better decisions about deprecating and removing it. See #2140 for details.

[whiteknight]

:immediate subs are really intended to do things to affect compilation, especially creating constants and inserting them into the constants table. Maybe it's not a bad design decision that we disallow certain operations to occur in these situations. IMCC is certainly a pain to try and make these kinds of changes for. I say we declare this an "implementation detail" of IMCC, and disallow it. Future PIR assemblers which are more capable and less fragile might be more tolerant of these kinds of things.

[whiteknight]

I'm closing this ticket as WONTFIX. :immediate subs are intended for affecting compilation and creating constants. These things happen at compile time, not at runtime. It is nonsensical to ask us to load a library during compile time, because the library won't necessarily be there for runtime, which would create all sorts of other problems.

That said, it's possible we want some kind of detection for this situation and a more graceful failure mode. For now, I'm saying it's an implementation detail of IMCC, this is behavior that we don't want to change in general. closing ticket.