Comment #18 on issue 2741 by [email protected]: max_opt_count is
implemented using the wrong kind of limit
http://code.google.com/p/v8/issues/detail?id=2741
Thank you for providing an actual patch to illustrate your proposal.
While I believe that this patch compiles and "works" just fine, I also
believe that it doesn't actually do anything. To find out if I'm right,
extend it as follows:
if (code()->ic_state() != PREMONOMORPHIC) {
// [original body of the method as in your patch]
} else {
printf("The patch prevented something!\n");
}
Then run your tests again and watch the output.
Based on the patch itself and your comments, I think there are a few more
misunderstandings:
To avoid patching code that is run only once
Almost. It still needs to be patched, but generating the map-dependent stub
can be deferred, which is a useful heuristic because it could be that (1)
it's never needed again if this code is indeed only run once, or (2) that
whatever map is seen first will never be seen again on subsequent runs, so
not storing it is a cheap way to avoid unneeded polymorphism.
keeping it in a premonomorphic state for too long preventing it from
being caught in an un-optimizable state
Firstly, as you already observed yourself, premonomorphic state is for code
that's run only once. So yeah, on the second run, it leaves premonomorphic
state. Secondly, premonomorphic state has nothing to do with being
optimizable or not.
if (code()->ic_state() != PREMONOMORPHIC) {
A function's unoptimized code object does not have an ic_state, only inline
cache stubs do.
preventing useless clearing of unchanging caches
Premonomorphic doesn't mean unchanging. Also, if it didn't matter whether
an inline cache is cleared or premonomorphic, then we wouldn't need
premonomorphic state, so it's hard to see why clearing them would
be "useless".
it basically makes the --max_opt_count flag from being abused
The patch doesn't really have anything to do with the --max-opt-count flag.
I also don't know what "abuse" you're talking about.
an un-optimizable stub
No stub is optimizable.
be constantly re-compiled
No stub is ever recompiled.
BTW it's funny seeing TODO(jkummerow)'s generously peppered around
Funny how? I find it rather sad. So much to do, so little time.
(Also, for the record, the name by a TODO comment does not indicate who
should take care of this task, but rather who can provide more details
about what exactly should be done there.)
I appreciate your interest in V8 and your efforts to contribute something.
However, as a word of warning, I'd like to point out that V8 is a very
complex project. If you don't have much experience with programming in
general and virtual machines in particular, it is probably not a suitable
project to start with: the learning curve will be very steep and the level
of frustration relatively high. I would specifically advise against trying
to change complex strategies such as when are functions optimized, when are
inline caches cleared, etc "on day #2", as you put it. It takes months,
sometimes years to get these right; and it's no secret that there are
remaining bugs and deficiencies that we know about, but fixing them is not
something that can be done in "maybe 10-30 mins max".
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
--
--
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/groups/opt_out.
