Comment #13 on issue 3907 by [email protected]: Allowing asm.js memory
growth causes big slowdown
https://code.google.com/p/v8/issues/detail?id=3907
We had discussions with Luke a few months ago about the changeHeap issue,
and a couple alternatives were discussed, including allocating large arrays
where the VM manages the underlying virtual memory and repointable array
views. The latter would require browser/API support while the concern with
the former was address space exhaustion on 32-bit platforms with a lot of
modules.
We're looking into different specialization strategies in TurboFan, and we
are also working on the support for speculation that would be needed to
support the ideas mentioned by dtc-v8@ above.
TurboFan does have support for deoptimization but it's not needed with our
current compilation strategy. Switching on deoptimization support results
in worse code (more stuff kept alive to recreate the unoptimized frames)
and more metadata. Both of those problems can be mitigated with some
techniques we are doing in Crankshaft, but that is not ready yet. Those are
in both active development but are several weeks, if not months, away.
--
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/d/optout.
