On Wed, Nov 5, 2014 at 9:03 AM, Vyacheslav Egorov <[email protected]> wrote:
> 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. > > Thanks for this comment. I have noticed that there is a --trace_stub_failures that traces deoptimizations for stubs in addition to the --trace_deopt flag. I admit that I don't have a very good understanding of what the semantic differences are for stubs is, but that is something I'm looking at and trying to understand the code. > 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. > > There are some research proposals for hardware support to reduce the cost of type checks. For instance the paper Checked Load: Architectural Support for JavaScript Type-Checking on Mobile Processors from HPCA 2011 ( https://homes.cs.washington.edu/~luisceze/publications/anderson-hpca2011.pdf ). I think that type of idea could be adapted to reduce the overhead of deoptimization checks. I don't know if the idea is worthwhile or not, but I think getting some estimate of the % overhead that deoptimization checks introduce could be useful for analyzing whether hardware support to reduce this overhead could be useful. So evaluating workloads with the deoptimization checks removed could be a form of limit study to see what the maximum potential benefit of hardware support to reduce their cost is. -Gabriel > > Vyacheslav Egorov > > On Wed, Nov 5, 2014 at 5:37 PM, Gabriel Southern <[email protected]> > 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 <[email protected]> >>> 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 >>>> [email protected] >>>> 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 [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> -- >> v8-users mailing list >> [email protected] >> 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 [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users > --- > You received this message because you are subscribed to a topic in the > Google Groups "v8-users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/v8-users/EY3cvrOw-Us/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- v8-users mailing list [email protected] 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
