lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

There is still a limit on the number of constants in a function (the
same 2^18). In our experience, most constructors repeat lots of constants,
so that was not a problem. But it may be for you. (Please let us know.
We may fix that in future versions, but only if there is real demand.)

Right, yeah I confirmed this for myself. This is definitely an issue for us, anyway. We hit the constant limit quite easily, particularly in projects with extensive paint strokes, or bezier shapes, or track points; which tend to generate large lists of co-ordinates at non-integer positions. The same number coming up many times would be the exception rather than the rule for us, in these cases.

However, I have now changed my version to work around this issue differently.

Rather than requiring a larger instruction word (and be incompatible with any libraries that contain 'compiled' code rather than text), I have added an OP_PRELOADK, which loads a prefix number for the high-bits of the constant index. This is only used if the constant table reference would exceed the Bx field size. Then the OP_LOADK will use this prefix value shifted up by SIZE_Bx, or'ed with its normal constant index.

I have added a varable to the lua_state to keep this prefix between opcodes, but I am a little concerned about the non-atomicity of this. While its always the case that an OP_PRELOADK will be followed by an OP_LOADK, if somehow (maybe with a hook), execution were yielded in-between my OP_PRELOADK and the OP_LOADK instructions, could this cause an issue? or is the lua_state not shared between co-routines?

Love, Light and Peace,
- Peter Loveday

----- Original Message ----- From: "Roberto Ierusalimschy" <>
To: "Lua list" <>
Cc: "Lua discussion list" <>
Sent: Thursday, July 13, 2006 11:38 PM
Subject: Re: bug report

So what is the limit on table constructors with this patch?

int size. Typically you will have other limits before this one, e.g. the
size of the block of memory holding the table hash. On my machine I went
up to 2^22 without errors.

I previously had to raise the limit of the 'B' and 'C' arg field sizes (and make the instruction word 64 bit to accomodate) to work around issues with
constructing large tables when loading our project files; am I correct in
thinking this will no longer be needed?

Also, what version(s) does this apply to?

5.1 (and 5.1.1).

-- Roberto