[Rd] strange increase in the reference number

[King Jiefei]

Hi Duncan, Gabriel, and Brodie

Thanks for the explanations and references. Brodie's blog talks about
exactly the same problem without involving too many technical details. I
would recommend to read it if anyone is interested in it. I really
appreciate all of you guys' answers.


Best,
Jiefei

On Sat, Jul 13, 2019 at 2:19 PM brodie gaslam via R-devel <
r-devel using r-project.org> wrote:

> Re ENSURE_NAMEDMAX, I am unsure but think this happens in (src/eval.c using 492
> ):
>  static SEXP forcePromise(SEXP e)
> {
>     if (PRVALUE(e) == R_UnboundValue) {
>     /* ... SNIP ...*/
>     val = eval(PRCODE(e), PRENV(e));
>     /* ... SNIP ...*/
>     SET_PRSEEN(e, 0);
>     SET_PRVALUE(e, val);
>     ENSURE_NAMEDMAX(val);                 <<<<<<< HERE
>     SET_PRENV(e, R_NilValue);
>     }
>     return PRVALUE(e);
> }
>
> as part of the evaluations of the closure.  `forcePromise` is called
> ineval (src/eval.c using 656).  It's been a while since I've looked at the
> mechanicsof how the native version of `eval` works so I could be completely
> wrong.
>
> B.
>
> PS: line references are in r-devel using 76287.
>
>
> On Friday, July 12, 2019, 4:38:06 PM EDT, Gabriel Becker <
> gabembecker using gmail.com> wrote:
>
>
>
>
>
> Hi Jiefei and Duncan,
>
> I suspect what is likely happening is that one of  ENSURE_NAMEDMAX or
> MARK_NOT_MUTABLE are being hit for x. These used to set named to 3, but now
> set it to 7 (ie the previous and current NAMEDMAX  value, respectively).
>
> Because these are macros rather than C functions, its not easy to figure
> out why one of them is being invoked from do_isvector  (a cursory
> exploration didn't reveal what was going on, at least to me) and I don't
> have the time to dig super deeply into this right now,  but perhaps Luke or
> Tomas know why this is happening of the top of their head.
>
> Sorry I can't be of more help.
>
> ~G
>
>
>
> On Fri, Jul 12, 2019 at 11:47 AM Duncan Murdoch <murdoch.duncan using gmail.com>
> wrote:
>
> > On 12/07/2019 1:22 p.m., King Jiefei wrote:
> > > Hi,
> > >
> > > I just found a strange increase in the reference number and I'm
> wondering
> > > if there is any reason for it, here is the code.
> > >
> > >> a=c(1,2,3)
> > >> .Internal(inspect(a))
> > > @0x000000001bf0b9b0 14 REALSXP g0c3 [NAM(1)] (len=3, tl=0) 1,2,3
> > >> is.vector(a)
> > > [1] TRUE
> > >> .Internal(inspect(a))
> > > @0x000000001bf0b9b0 14 REALSXP g0c3 [NAM(7)] (len=3, tl=0) 1,2,3
> > >
> > > The variable *a* initially has one reference number, after calling
> > > *is.vector* function, the reference number goes to 7, which I believe
> is
> > > the highest number that is allowed in R.  I also tried the other R
> > > functions, *is.atomic, is.integer* and *is.numeric* do not increase the
> > > reference number, but *typeof *will do. Is it intentional?
> >
> > is.vector() is a closure that calls .Internal.  is.atomic(),
> > is.integer() and is.numeric() are all primitives.
> >
> > Generally speaking closures that call .Internal are easier to implement
> > (e.g. is.vector can use the regular mechanism to set a default for its
> > second argument), but less efficient in CPU time.  From it's help page,
> > it appears that the logic for is.vector() is a lot more complex than for
> > the others, so that implementation does make sense.
> >
> > So why does NAMED go to 7?  Initially, the vector is bound to a.  Within
> > is.vector, it is bound to the local variable x.  At this point there are
> > two names bound to the same object, so it has to be considered
> > immutable.  There's really no difference between any of the values of 2
> > or more in the memory manager.  (But see
> > http://developer.r-project.org/Refcnt.html for some plans.  That
> > document is from about 5 years ago; I don't know the current state.)
> >
> > Duncan Murdoch
> >
> > ______________________________________________
> > R-devel using r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>     [[alternative HTML version deleted]]
>
>
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>         [[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

	[[alternative HTML version deleted]]