Not quite, this is already checked on octane and asm.js tests,
and we have margins over 100MB free space for code space.
Yes, there is concern for extreme JS code size in future and we are aware of
that.
Also we have strategy for this problem. It is only matter of decision
whether we
limit code size to 256mb and use J/JAL instructions for long branches which
will
also give us opportunity to use them for calls, or use them for long
branches
only within code objects which does not require code range limiting to
256MB.
In later above-mentioned approach I can tweak code range allocator to be
"unlimited" (limited to 512mb as for x64), but it has to take care to not
allocate code objects across
256-MB regions for mips64 only. I can add this in next patch set or next CL,
therefore please approve this CL if you think memory allocator tweaks is
more
suitable for next CL, otherwise I will create next patch set.
https://codereview.chromium.org/1147503002/
--
--
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.
