Closed Bug 607223 Opened 14 years ago Closed 14 years ago

AOT tidyup

Categories

(Tamarin Graveyard :: Virtual Machine, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: alexmac, Unassigned)

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; en-us) AppleWebKit/533.18.1 (KHTML, like Gecko) Version/5.0.2 Safari/533.18.5
Build Identifier: 

In preparation for open-sourcing the AOT opcode stub implementations this patch cleans up the rest of the AOT related code by:

-- fixing some compiler warnings
-- removing some dead code in Cdecl
-- properly ifdefing Cdecl with VMCFG_CDECL
-- adding a friendly error message if avmshell-aot is compiled without any aot compiled abcs
-- removing unnecessary AOTCompiler.h includes
-- fixing the avmfeatures aot spec to properly prevent AOT being turned on along with the JIT or interpreter


Reproducible: Always
Attached patch AOT tidyupSplinter Review
Attachment #485976 - Flags: review?(stejohns)
Attachment #485976 - Flags: review?(cpeyer)
Comment on attachment 485976 [details] [diff] [review]
AOT tidyup

R+ for build files.
Attachment #485976 - Flags: review?(cpeyer) → review+
Attachment #485976 - Flags: review?(stejohns) → review+
maybe better late than never, but some documentation on the new AOT specific workaround functions would be very helpful, for example on:

hookUpActivationTraitsInitMethodForTraitsMethod() in Traits.cpp.

if there was a single doc under docs explaining "how it works" then the per-function comments should be brief.  I'd just like to see enough breadcrumbs so a person new to the code can find their way to a description of how the odd cases are handled, like activation traits, object initialization, etc.

(unrelated: the VM no longer generates ABC on the fly for object initialization.  Did this simplify AOT? one would think so).
TR 5402:8c05245736c6
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
(In reply to comment #3)
> maybe better late than never, but some documentation on the new AOT specific
> workaround functions would be very helpful, for example on:
> 
> hookUpActivationTraitsInitMethodForTraitsMethod() in Traits.cpp.
> 
> if there was a single doc under docs explaining "how it works" then the
> per-function comments should be brief.  I'd just like to see enough breadcrumbs
> so a person new to the code can find their way to a description of how the odd
> cases are handled, like activation traits, object initialization, etc.

absolutely, I'm working on a writeup of AOT as we speak.

> (unrelated: the VM no longer generates ABC on the fly for object
> initialization.  Did this simplify AOT? one would think so).

Yeah we had to synthesize init methods in the AOT compiler to handle just this case. If the VM now does that without generating abc then we can definitely take advantage of it.
(In reply to comment #5)
> Yeah we had to synthesize init methods in the AOT compiler to handle just this
> case. If the VM now does that without generating abc then we can definitely
> take advantage of it.

See BaseExecMgr::initObj(), called by initInterpGPR(), initInterpFPR(), initInvokeInterp(), and initInvokeInterpNoCoerce().  When calling an interpreted constructor, these stubs make the object get initialized first.  (same as what the generated abc used to do).

When we invoke a jit-compiled constructor, the field init assignments are still generated.  the AOT compiler could use initObj(), or could generate the initializing assignments like the JIT does, based on the traits. (come to think of it, maybe this doesn't simplify anything for AOT; at least abc generation is gone).
(In reply to comment #6)
> When we invoke a jit-compiled constructor, the field init assignments are still
> generated.  the AOT compiler could use initObj(), or could generate the
> initializing assignments like the JIT does, based on the traits. (come to think
> of it, maybe this doesn't simplify anything for AOT; at least abc generation is
> gone).

so the jit isn't generating these initializers as abc, but it's still jitting code right? If that's the case we can't do whatever it is doing. We could definitely use initObj, but presumably that will be slower than just sticking with the methods we generate right now.
(In reply to comment #7)
> so the jit isn't generating these initializers as abc, but it's still jitting
> code right?

Right

> If that's the case we can't do whatever it is doing. 

You can't JIT-compile, but you can iterate over the concrete fields of the declaring type, and generate code at the beginning of the AOT-generated constructor, analogous to what the JIT does.

> We could definitely use initObj, but presumably that will be slower than
> just sticking with the methods we generate right now.

Agreed.  After writing comment #6 it just became obvious that the AOT compiler won't be improved after all.
(In reply to comment #8)
> You can't JIT-compile, but you can iterate over the concrete fields of the
> declaring type, and generate code at the beginning of the AOT-generated
> constructor, analogous to what the JIT does.

yeah, we do exactly this, but of course we have to do this at compile time outside the vm as we can't execute generated code at runtime.

> 
> > We could definitely use initObj, but presumably that will be slower than
> > just sticking with the methods we generate right now.
> 
> Agreed.  After writing comment #6 it just became obvious that the AOT compiler
> won't be improved after all.

Although as Stan just pointed out, this probably wouldn't affect us right now as we have bigger performance bottlenecks in other places. It might however simplify the AOT compiler and make maintaining it easier.

It might also improve AOT compile times so it could be a useful addition to debug mode where we want to generate code as fast as possible.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: