From: Markus <markus@...>
Date: 2004-10-27T13:55:37+09:00
Subject: Re: Errors in line numbers reported?

On Tue, 2004-10-26 at 17:47, nobu.nokada@softhome.net wrote:
> Hi,
> 
> At Wed, 27 Oct 2004 01:58:51 +0900,
> Markus wrote in [ruby-talk:117790]:
> >       This seems to be along the lines I was thinking, but there seems
> > to be more to it than I was imagining, and I do not understand all of
> > it.  Why is the interaction with the GC needed?  Wouldn't it be enough
> > to allocate them and keep them around forever?
> 
> Do you mean:
> 
>   typedef struct {
>   #ifdef NODE_SEGMENTED_LINENO
>       unsigned char lineno_upper;
>   #endif
>       char gcmark, name[1];
>   } srcfilename;
> 
> and
> 
>     ptr = ALLOC_N(char, len + offsetof(srcfile, name));
>     ...
>     srcfilename *ptr = (srcfilename *)(f - offsetof(srcfile, name));
> ?

      No, I meant something like:

  typedef struct {
      unsigned long lineno_offset;
      char *nd_file;
  } srcfile_segment;

I was intending to share the (unaltered) file name among all the segments.  

> >      I was thinking it could be done by patching node.h (to add and
> > adjust macros), eval.c (to use them), and parse.y, to make a small
> > struct with int line_number_offset and char *file_name to store in the
> > RNODEs in place of nd_file.  The main complexity would be making a new
> > current struct any time a RNODE was created and 
> > 
> >         ruby_sourceline - current->line_number_offset >= 8*1024
> > 
> >      Is there a reason that I am not seeing why this would not work?
> 
> To save memory space.

     If B is the number of 8K-line blocks (rounded up) in a file, and N
is the number of bytes in the file name (including the path), we have an
overhead of:

     8*B+N

or 

     (2+N)*B 

So the savings is six bytes per source file, not counting the additional
code complexity (and size), and assuming that no file has more than 8k
lines (in which case we give back N, ~= 40).   

     Not a significant difference in any case.

     I'm playing with a patch which should handle up to 4 billion lines
with no memory penalty at all (or perhaps a very slight gain), and
potentially much simpler code (so probably a net speed increase) but am
running into problems with how the members of the union are referenced. 
I'm finding cases where (for example) u1.value is used to reference a
member of u2 or u3 that happens to occupy the same memory location.  Is
there and documentation of where/when this is considered appropriate?

     -- Markus