On Tuesday, March 11, 2014 12:44:00 PM UTC-7, Jakob Kummerow wrote: > > On Tue, Mar 11, 2014 at 5:41 PM, Hendrik Greving > <[email protected]<javascript:> > > wrote: > >> On Tuesday, March 11, 2014 5:57:40 AM UTC-7, Jakob Kummerow wrote: >> >>> On Mon, Mar 10, 2014 at 7:34 PM, Hendrik Greving <[email protected] >>> > wrote: >>> >>>> I am looking for the proper approach to do the following avoiding >>>> memory leaks. I need to create some meta info for code objects, e.g. >>>> Crankshaft compiled code. The meta info has to live as long as the code is >>>> in the code cache, and is accessed from outside world. Right now, I am >>>> allocating space (just using 'new') in Compiler::GetOptimizedCode and >>>> attach to code, by putting in the same DECL_ACCESSORS as e.g. gc_metadata. >>>> My assumption is, that hence garbage collection knows about the additional >>>> pointer in "class Code", and that this space will get freed when the Code >>>> is release, too. Is this assumption correct? >>>> >>> >>> No. The garbage collector doesn't know anything about C++ memory. In >>> fact, what you're describing is highly unsafe and only happens to work >>> because the allocated object happens to be aligned, so the GC thinks it's a >>> Smi and ignores it. You'll have to put your meta data into a heap object. >>> Good luck. >>> >> >> Primarily what I want to make available to the outside world (through an >> here unspecified mechanism) are primarily addresses (IP's!). I kind of >> figured what you're saying, which is why, as a first try, I encapsulated >> the addresses into a FixedArray HeapObject. Question is, will GC leave the >> array element (look like pointers?!) alone? >> > > Depends on what you mean by "look like pointers", and whether you teach > the GC how to handle your modified Code objects. > > >> Let me go one step back, what should be the fundamental motivation for me >> to actually use V8's managed heap memory for what I'm doing? Is it possible >> to just use C++/OS memory for this? >> > > You said you wanted the lifetime of your objects managed by V8's GC. The > GC only manages the lifetime of objects on the V8 heap. I'm sure > alternative designs are possible (they always are), but I don't have a > concrete suggestion how to solve your task. I suspect it'll be quite messy > either way, since this kind of thing is not supported by the API or the > general architecture. >
I think the optimized code map as part of the shared function info does similar things, and is part of the V8's heap. The reason I am asking is, because I am mainly storing program addresses, and I stored them as double values using a FixedDoubleArray but having some trouble (assertion map() != GetHeap()->fixed_arrray_map() is firing). And before figuring this out, I was re-thinking why I am putting in things into V8's heap in the first place, as opposed to C++'s memory. Are there things belonging to one isolate, that V8 generally puts into C++'s memory, by 'manually managing' it, or is this not advisable due to e.g. security aspects? -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
