Re: [racket-users] Re: C++ and pointer registration with 3M?

2019-11-01 Thread Thomas Dickerson
On Fri, Nov 1, 2019 at 6:04 PM Matthew Flatt wrote: > Just unnecessary. Great :) > It's not common, but that can happen. The GC can recognize and ignore > pointers that are not to its own space. This also fits my mental model, but I wanted to make sure I understood the corner cases. >

Re: [racket-users] Re: C++ and pointer registration with 3M?

2019-11-01 Thread Matthew Flatt
At Fri, 1 Nov 2019 17:15:57 -0400, Thomas Dickerson wrote: > Is it an error to register things which are not GCable, or just unnecessary? Just unnecessary. > Also - are there ever likely to be pointers which could hold memory which > may or may not be GCable depending on the code path? > (e.g. a

Re: [racket-users] Re: C++ and pointer registration with 3M?

2019-11-01 Thread Thomas Dickerson
Great, this is very helpful. On Fri, Nov 1, 2019 at 4:53 PM Matthew Flatt wrote: > At Fri, 1 Nov 2019 10:34:50 -0700 (PDT), Thomas Dickerson wrote: > Only pointers to GCable memory --- which tends to be the things passed > to a Racket function, but more generally corresponds to things that >

Re: [racket-users] Re: C++ and pointer registration with 3M?

2019-11-01 Thread Matthew Flatt
At Fri, 1 Nov 2019 10:34:50 -0700 (PDT), Thomas Dickerson wrote: > The documentation says: > "The 3m collector needs to know the address of every local or temporary > pointer within a function call at any point when a collection can be > triggered." > > A couple questions: > - Is this "every

[racket-users] Re: C++ and pointer registration with 3M?

2019-11-01 Thread Thomas Dickerson
Sorry for the double-post, one more question. The output of `raco ctool --c-mods` has the form: #ifdef MZ_XFORM > XFORM_START_SKIP; > #endif > static void declare_modules(Scheme_Env *env) { > static unsigned char data[] = { /* bytes go here */ }; > scheme_register_embedded_load(NUM_BYTES,