Closed Bug 1169213 Opened 9 years ago Closed 9 years ago

[MBaselineCache] Add frame type for an IonStub

Categories

(Core :: JavaScript Engine: JIT, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla41
Tracking Status
firefox41 --- fixed

People

(Reporter: h4writer, Assigned: h4writer)

References

Details

Attachments

(1 file)

      No description provided.
Blocks: 1161516
This introduces JitFrame_IonStub. This will make it possible to do vmcalls out of sharedstubs (baseline stubs that work also in ionmonkey).
Assignee: nobody → hv1989
Attachment #8612288 - Flags: review?(nicolas.b.pierron)
Comment on attachment 8612288 [details] [diff] [review]
bug1169213-jitframe-ionstub

Review of attachment 8612288 [details] [diff] [review]:
-----------------------------------------------------------------

Ask me for review on the code which is using the JitFrame_IonStub.

::: js/src/jit/JitFrames.cpp
@@ +1540,5 @@
>            case JitFrame_IonJS:
>              MarkIonJSFrame(trc, frames);
>              break;
> +          case JitFrame_IonStub:
> +            MarkIonStubFrame(trc, frames);

Rename MarkIonStubFrame to MarkJitStubFrame and use it for both baseline and Ion stub frames.

::: js/src/jit/JitFrames.h
@@ +893,5 @@
>  }
>  
>  class ICStub;
>  
> +class IonStubFrameLayout : public CommonFrameLayout

JitStubFrameLayout?

@@ +898,4 @@
>  {
> +    // Info on the stack
> +    // Note: The stack architecture grows down. Thus sequence in stack is
> +    // in the opposite order as class members.

The sequence of data in the stack is the same as in the class, otherwise reinterpret_cast of stack pointers would never work.
What you probably meant is the content has to be "pushed to" the stack in opposite order, as the stack pointer grows down when we push, but this is not specific to this class.

Thus, I think this comment does not bring any value and I recommend to remove it.

@@ +906,5 @@
> +    // | - Descriptor     | => Marks end of JitFrame_IonJS
> +    // | - returnaddres   |
> +    // +------------------+
> +    // | - StubPtr        | => First thing pushed in a stub only when the stub will do
> +    // --------------------    a vmcall. Else we cannot have IonStubFrame.

I guess this is inherited from legacy code, but why StubPtr is not a member of this class?
Maybe Kannan or Jandem can answer?

@@ +927,5 @@
> +class BaselineStubFrameLayout : public IonStubFrameLayout
> +{
> +    // Info on the stack
> +    // Note: The stack architecture grows down. Thus sequence in stack is
> +    // in the opposite order as class members.

Remove this part of the comment.
Attachment #8612288 - Flags: review?(nicolas.b.pierron) → review+
https://hg.mozilla.org/mozilla-central/rev/63b1e449beda
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: