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 at 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 at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >[[alternative HTML version deleted]]
Re ENSURE_NAMEDMAX, I am unsure but think this happens in (src/eval.c at 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 at 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 at 76287.
On Friday, July 12, 2019, 4:38:06 PM EDT, Gabriel Becker <gabembecker at
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 at
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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
??? [[alternative HTML version deleted]]
______________________________________________
R-devel at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
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 at r-project.org> wrote:> Re ENSURE_NAMEDMAX, I am unsure but think this happens in (src/eval.c at 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 at 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 at 76287. > > > On Friday, July 12, 2019, 4:38:06 PM EDT, Gabriel Becker < > gabembecker at 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 at 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 at r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > [[alternative HTML version deleted]] > > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >[[alternative HTML version deleted]]