Hydrogen is also used to generate stubs and there CheckMaps "deopt" has a
different semantics from a normal deopt - and it is not reported in
--trace-deopt (which reports all normal JS function deopts). You have to
accommodate for that in your experiments.
I however think that your experiment does not provide any actionable data.
Knowing that checks introduce X% overhead is kinda useless - unless you
also know an algorithm to eliminate all of them and retain correctness.
Vyacheslav Egorov
On Wed, Nov 5, 2014 at 5:37 PM, Gabriel Southern <souther...@gmail.com>
wrote:
> Perhaps it would help if I explained my motivation. I'm trying to
> evaluate the overhead of conditional deoptimization checks. One way is by
> running workloads that have the checks in their normal configuration and
> measuring the runtime. Then removing checks that were never triggered and
> rerunning the workload and comparing the runtime. Obviously I understand
> this is not safe in the general case.
>
> For some workloads I was able to remove the call to DeoptimizeIf in
> LCodeGen::DoCheckMaps and the benchmark still ran correctly. But if I
> removed the call to CompareMap(reg,map) I would get an error about
> unreachable code similar to what I posted earlier when I remove the
> CompareMaps hydrogen instructions.
>
> Aside from that I think that I want to be able to choose when to remove
> checks at the hydrogen instruction level because later I will want to pick
> which functions to remove the checks from. I would profile a benchmark
> first and see which functions have conditional deopts that are never
> triggered and then remove the deopts from those functions.
>
> Again this is all part of a performance evaluation study, not something to
> be used for production code. I hope this makes sense, but if you think
> there's something I'm overlooking for why this won't work I'd be interested
> to know why. From looking at the assembly code sequences that are
> generated I think this should be okay, but there's also obviously something
> I'm missing that is leading to the unreachable code error that I've seen.
>
> Thanks,
>
> -Gabriel
>
> On Wednesday, November 5, 2014 5:42:20 AM UTC-8, Jakob Kummerow wrote:
>>
>> Removing check instructions is so utterly wrong and dangerous that I
>> can't bring myself to even try to help you. Just don't do it!
>>
>>
>> On Wed, Nov 5, 2014 at 8:19 AM, Gabriel Southern <south...@gmail.com>
>> wrote:
>>
>>> I'm experimenting with removing deoptimization checks and I have a
>>> question about how to remove hydrogen instructions.
>>>
>>> I'm looking at a benchmark where the CheckMaps deoptimization checks are
>>> never triggered and I'm trying to remove them. I know this is not safe in
>>> the general case, but when I traced the deoptimizations for this benchmark
>>> there were not any that were triggered because of CheckMaps.
>>>
>>> I've tried to follow the HDeadCodeEliminationPhase as a guide because
>>> what I want to do is delete instructions that match a certain criteria, so
>>> I thought that pass might be a good example. The main loop in my pass is:
>>>
>>> for (int i = 0; i < graph()->blocks()->length(); ++i) {
>>> HBasicBlock* block = graph()->blocks()->at(i);
>>> for (HInstructionIterator it(block); !it.Done(); it.Advance()) {
>>> HInstruction* instr = it.Current();
>>> if (instr->opcode() == HValue::kCheckMaps) {
>>> instr->DeleteAndReplaceWith(NULL);
>>> }
>>> }
>>> }
>>>
>>> When I run this and just print the list of instructions that will be
>>> removed the list looks okay. However if I actually delete the instruction
>>> I get a runtime error as follows:
>>>
>>> #
>>> # Fatal error in ../src/objects.cc, line 10380
>>> # unreachable code
>>> #
>>>
>>> ==== C stack trace ===============================
>>>
>>> 1: V8_Fatal
>>> 2:
>>> v8::internal::Code::FindAndReplace(v8::internal::Code::FindAndReplacePattern
>>> const&)
>>> 3:
>>> v8::internal::CodeStub::GetCodeCopy(v8::internal::Code::FindAndReplacePattern
>>> const&)
>>> 4: v8::internal::PropertyICCompiler::ComputeCompareNil(v8::
>>> internal::Handle<v8::internal::Map>, v8::internal::CompareNilICStub*)
>>> 5: v8::internal::CompareNilIC::CompareNil(v8::internal::
>>> Handle<v8::internal::Object>)
>>> 6: ??
>>> 7: v8::internal::CompareNilIC_Miss(int, v8::internal::Object**,
>>> v8::internal::Isolate*)
>>> 8: ??
>>> Segmentation fault (core dumped)
>>>
>>> I'm wondering if anyone has suggestions for what I can look at it
>>> understand what's going on and debug the problem. Obviously the specific
>>> thing I'm trying to do of removing CheckMaps is not something that should
>>> work in general. But I think it should be possible to remove a hydrogen
>>> instruction during the optimization phase. I've tried to pattern my
>>> attempt off of the existing code, but obviously I'm missing something. If
>>> anyone has suggestions about what I should try that is appreciated.
>>>
>>> Thanks,
>>>
>>> Gabriel
>>>
>>> --
>>> --
>>> v8-users mailing list
>>> v8-u...@googlegroups.com
>>> http://groups.google.com/group/v8-users
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "v8-users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to v8-users+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
