Closed
Bug 1364615
Opened 9 years ago
Closed 9 years ago
Baldr: tidy up some things about wasm::Code
Categories
(Core :: JavaScript Engine, enhancement)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
mozilla55
| Tracking | Status | |
|---|---|---|
| firefox55 | --- | fixed |
People
(Reporter: luke, Assigned: luke)
Details
Attachments
(4 files)
|
13.24 KB,
patch
|
lth
:
review+
|
Details | Diff | Splinter Review |
|
4.28 KB,
patch
|
lth
:
review+
|
Details | Diff | Splinter Review |
|
3.26 KB,
patch
|
jandem
:
review+
|
Details | Diff | Splinter Review |
|
19.66 KB,
patch
|
lth
:
review+
|
Details | Diff | Splinter Review |
A couple small cleanup patches.
| Assignee | ||
Comment 1•9 years ago
|
||
This patch adds a new UniquePtr typedef that releases code which makes ownership of code more foolproof.
Attachment #8867409 -
Flags: review?(lhansen)
| Assignee | ||
Comment 2•9 years ago
|
||
Attachment #8867410 -
Flags: review?(lhansen)
| Assignee | ||
Comment 3•9 years ago
|
||
(Oops, hit enter too soon.) The patch in comment 2 avoids the somewhat strange unlinkedBytesForDebugging() by instead making a copy of the bytes directly from the MacroAssembler before linking. Also should be a tiny bit faster.
| Assignee | ||
Comment 4•9 years ago
|
||
We're no longer doing mixed X/W mappings so, as the comment says...
Attachment #8867411 -
Flags: review?(jdemooij)
| Assignee | ||
Comment 5•9 years ago
|
||
This patch removes maybeBytecode from wasm::Code since wasm::Code basically has no need for it. Instead, the 1 use (passing maybeBytecode_ to Metadata::getFuncName) is done in Instance instead which already has access to maybeBytecode via debug_. This keeps wasm::Code more focused on just executable code, which I think is better.
Attachment #8867412 -
Flags: review?(lhansen)
Comment 6•9 years ago
|
||
Comment on attachment 8867411 [details] [diff] [review]
rm-alloc-limit
Review of attachment 8867411 [details] [diff] [review]:
-----------------------------------------------------------------
Nice.
Attachment #8867411 -
Flags: review?(jdemooij) → review+
Comment 7•9 years ago
|
||
Comment on attachment 8867409 [details] [diff] [review]
unique-code-bytes
Review of attachment 8867409 [details] [diff] [review]:
-----------------------------------------------------------------
::: js/src/wasm/WasmCode.h
@@ +57,5 @@
> typedef UniquePtr<const CodeSegment> UniqueConstCodeSegment;
>
> class CodeSegment
> {
> + // Executable code must be release deallocated specially.
Presumably "deallocated" is all you mean and "release" should be removed.
Attachment #8867409 -
Flags: review?(lhansen) → review+
Updated•9 years ago
|
Attachment #8867410 -
Flags: review?(lhansen) → review+
Comment 8•9 years ago
|
||
Comment on attachment 8867412 [details] [diff] [review]
rm-code-bytecode
Review of attachment 8867412 [details] [diff] [review]:
-----------------------------------------------------------------
Nice. I strongly favor this, (even if it will interact in an ugly way with a long patch queue I have).
Attachment #8867412 -
Flags: review?(lhansen) → review+
Pushed by lwagner@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/94bc2a2c7274
Baldr: use UniquePtr to own code (r=lth)
https://hg.mozilla.org/integration/mozilla-inbound/rev/b8bbd7e9579a
Baldr: remove unlinkedBytesForDebugging (r=lth)
https://hg.mozilla.org/integration/mozilla-inbound/rev/4901d885b1a4
Baldr: remove MaxWasmCodeAllocations (r=jandem)
https://hg.mozilla.org/integration/mozilla-inbound/rev/2e27f56d21b4
Baldr: remove bytecode from wasm::Code (r=lth)
Comment 10•9 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/94bc2a2c7274
https://hg.mozilla.org/mozilla-central/rev/b8bbd7e9579a
https://hg.mozilla.org/mozilla-central/rev/4901d885b1a4
https://hg.mozilla.org/mozilla-central/rev/2e27f56d21b4
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox55:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
You need to log in
before you can comment on or make changes to this bug.
Description
•