Questions about concurrent recompilation for Crankshaft

[Jay]

Hi,

I have some questions about concurrent recompilation for Crankshaft.

1. Crankshaft's compilation is 3-step: CreateGraph, OptimizeGraph and GenerateCode.  It seems like only the second step is done on the background thread concurrently.  What prevents the other steps to be parallelized as well?

2. It seems like that it does not use concurrent recompilation for OSR.  Why is it?

Thanks,

Jay

[Jochen Eisinger]

On Thu, Nov 10, 2016 at 9:30 PM Jay <jra...@gmail.com> wrote:

Hi,

I have some questions about concurrent recompilation for Crankshaft.

1. Crankshaft's compilation is 3-step: CreateGraph, OptimizeGraph and GenerateCode.  It seems like only the second step is done on the background thread concurrently.  What prevents the other steps to be parallelized as well?

The other steps access javascript objects on the heap, an operation that is not thread-safe in v8.

 

2. It seems like that it does not use concurrent recompilation for OSR.  Why is it?

For OSR, we need the code as soon as possible. We used to use concurrent recompilation for this, but it often happened that when the code was compiled, we no longer needed it.

 

Thanks,

Jay

--
--
v8-dev mailing list
v8-...@googlegroups.com
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 v8-dev+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Leszek Swirski]

On Fri, Nov 11, 2016 at 12:28 AM, Jochen Eisinger <joc...@chromium.org> wrote:

For OSR, we need the code as soon as possible. We used to use concurrent recompilation for this, but it often happened that when the code was compiled, we no longer needed it.

This line of reasoning is odd, if compilation time takes longer than un-compiled execution time, should we be compiling at all?

- Leszek

[Yang Guo]

Concurrent OSR used to work like this:

- When we decide to OSR at a loop entry, we create a compile job to have it compiled, mostly on the concurrent thread.

- In the meantime we continue with the function.

- Once the compile job is complete, we patch that loop entry to install the code.

- If we arrive at the loop entry again, the code is installed and we OSR into optimized code.

- As long as we don't arrive at the loop entry, the compile job is on-hold and holds onto memory.

- We may never arrive at that loop entry again. So to reduce the risk of memory leaks, we periodically purge on-hold OSR jobs.

In practise, concurrent OSR almost never helps, and we had a couple of pathological cases where the function to OSR is huge, has a few separate long-running loops. We decide to OSR for each of them, but miss the loop-reentry, and only return to a loop-entry when old OSR jobs have been purged. The complexity of all of this is just not worth the hassle.

Cheers,

Yang 

--

[Jiho Choi]

Thanks for the answers!

I thought OSR is triggered after you reach the loop entry several times for hot loops, and it is more likely than not to reach the loop entry again in the future, but I guess the real-world workloads do not behave this way.

Could you provide more explanation on the first question (e.g. what kinds of JavaScript objects are needed)? I thought the first step, CreateGraph, is mostly parsing from source codes to Hydrogen IR, and the last step, GenerateCode, is mostly lowering the optimized Hydrogen IR to Lithium and then to machine codes. In my mind, both of them sounds like steps independent on dynamic JavaScript objects.

Thanks,

Jay

You received this message because you are subscribed to a topic in the Google Groups "v8-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/v8-dev/SIDcNHAGiU8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to v8-dev+un...@googlegroups.com.