Specifically, I think there are some VMs that rely on the hardware to raise exceptions to catch the failure caused by the violated assumption, in which case this is quite similar to handling a crash ...
-- Dirk On Tue, Jul 30, 2013 at 6:13 PM, Casey Ransberger <[email protected]>wrote: > Hi Dirk, yes I am aware of dynamic VMs that deoptimize when their > heuristics for what to precompile fail. Most of the JIT/PIC VMs do this. > But my gut says what I'm asking about is a bit different than that. Of > course, maybe it isn't. Falling back to interpreter logic, now that you > mention it, isn't so different from what I'm asking about at all. > > Good point. You know, if I didn't have you folks around, I might start > thinking that my ideas were original:) > > > On Jul 30, 2013, at 5:58 PM, Dirk Pranke <[email protected]> wrote: > > On Tue, Jul 30, 2013 at 1:22 PM, Casey Ransberger < > [email protected]> wrote: > >> Thought I had: when a program hits an unhandled exception, we crash, >> often there's a hook to log the crash somewhere. >> >> I was thinking: if a system happens to be running an optimized version of >> some algorithm, and hit a crash bug, what if it could fall back to the >> suboptimal but conceptually simpler "Occam's explanation?" >> >> All other things being equal, the simple implementation is usually more >> stable than the faster/less-RAM solution. >> >> Is anyone aware of research in this direction? >> > > This sounds fairly close to "compiler deoptimization", which is fairly > common in just-in-time compiler technology (see v8, the self system, > probably jvms do it also ...). Perhaps you could start there? > > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.4338 > http://www.cs.ucsb.edu/~urs/oocsb/self/papers/dynamic-deoptimization.html > > -- Dirk > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
