Closed Bug 561200 Opened 14 years ago Closed 13 years ago

TM: Why do we set up a deep bail state around Method(Read/Write)Barrier?

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: gal, Unassigned)

Details

Neither me nor jorendorff understand whats going on there. We guard on OOM, not STATUS_EXIT.
Summary: TM: Why do we set up a deep bail state around Method(Read/Write)Barrier → TM: Why do we set up a deep bail state around Method(Read/Write)Barrier?
MethodReadBarrier calls js_SetProperty, which must be what motivated the deep bail stuff. But it needs to be FAIL_STATUS and its calling code guard on STATUS_EXIT? I forget why the WriteBarrier deep bail stuff is there; on the go at the moment so not able to dig further than this:

$ hg log -r32130
changeset:   32130:842e6c09e35a
user:        Brendan Eich <brendan@mozilla.org>
date:        Thu Sep 03 14:41:19 2009 -0700
summary:     Join lambdas assigned or initialized as methods to the compiler-created function object if we can, with a read barrier to clone on method value extractions other than call expressions (471214, r=jorendorff).

Jason, do you remember more after looking through the comments in bug 471214?

/be
I don't think MethodReadBarrier needs _STATUS either. It calls js_SetProperty, but given the preconditions, I don't think that can fail except by running out of memory.
Group: core-security
Group: core-security
Whiteboard: [sg:critical]
Whiteboard: [sg:critical]
Obsolete with the removal of tracejit.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.