So now I am trying to read dump of alias information produced by
-fdump-tree-alias for my problematic translation unit and here is what
I see:
void Genesis::HookUpGlobalProxy(Handle<GlobalObject> inner_global,
Handle<JSGlobalProxy> global_proxy) {
// ...
inner_global->set_global_context(*global_context());
// ...
}
source.55_37 = (struct GlobalObject * * * {ref-all}) &D.79958;
D.79961_38 = *source.55_37;
# DEBUG dest => D.79961_38
D.79957_39 = *D.79961_38;
D.79957_43 = D.79957_39;
D.79957_17 = D.79957_43;
v8::internal::GlobalObject::set_global_context (D.79957_17, D.71929_2, 1);
where
D.79957_17, points-to vars: { }
if I am reading this correctly this means exactly what we discussed
earlier: GCC decided that pointer to GlobalObject stored inside handle
inner_global is not aliasing anything and then (after inlining
set_global_context) removed writes to
through it.
I will continue digging this.
--
Vyacheslav Egorov
On Sat, Oct 2, 2010 at 1:15 AM, Ian Lance Taylor <iant@xxxxxxxxxx> wrote:
> Vyacheslav Egorov <vegorov@xxxxxxxxxxxx> writes:
>
>> On Sat, Oct 2, 2010 at 12:37 AM, Ian Lance Taylor <iant@xxxxxxxxxx> wrote:
>>> Well, also, you need to allocate Object* values using malloc or placement new, not, say, new
>>> char[].
>>
>> We use a custom allocators which do not rely on any of these [we mmap
>> pages and treat pieces of mmap'ed pages as objects]. Is this a
>> problem?
>
> That should be fine. Anything which essentially acts like malloc should
> be fine. The difference is that new char[] returns memory which already
> has a type, and malloc or mmap do not.
>
> Ian
>
