Re: bug report

["Peter Loveday" <peter@...>]

> 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" <roberto@inf.puc-rio.br>
To: "Lua list" <lua@bazar2.conectiva.com.br>
Cc: "Lua discussion list" <lua-l@lua.org>
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