On 2015/02/18 10:08:04, Jakob wrote:
I would think that fixing the existing OOL constant pool implementation
is a
lot
less work than implementing a new one.
I'm not sure whether the existing implementation should be kept if you
end up
deciding to do your own thing, but I would err on the side of caution and
keep
it. Ross tells me that the performance benefit isn't great right now, but
I'm
kind of hopeful that avoiding code patching altogether would be
beneficial on
some platforms. For that, we need three pieces as far as I'm aware: (1)
vector
ICs (work in progress), (2) OOLCP, (3) a non-patching code ageing
mechanism.
For reference, here is the implementation of the alternate solution I
proposed
in
comment #3. This provides the same performance benefit on PPC as the
current
OOL
solution, with none of the complexity and issues associated with the
ConstantPoolArray object.
Let us know whether this looks like a reasonable approach to you.
https://github.com/andrewlow/v8ppc/commit/9ef98ea5b70d2d5bfa712c5507ce6f2ac3d73341
Introduce alternate OOL constant pool mode.
This provides an alternate mode for out-of-line constant pools. The
new mode supports the placement of a contiguous constant pool at the
end of the code buffer rather than a separate heap object. It
leverages the traditional mode's common code infrastructure for
maintaining a dedicated constant pool base register, but does not
require the ConstantPoolArray heap object.
https://codereview.chromium.org/882263003/
--
--
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/d/optout.
