Bug 28701 – How many copies of the parameters do you need?

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Gavin Barraclough]

The function parameters in JSC get copied a lot - and unnecessarily so.

Originally this happened due to duplicating FunctionBodyNodes on recompilation, though the problem has been exacerbated by copying the parameters from the original function body onto the executable, then back onto the real body that will be generated (this happens on every function).  And this is all made worse since the data structures in question are a little ugly - C style arrays of C++ objects containing ref counts, so they need a full copy-construct (rather than a simple memcpy).

This can all be greatly simplified by just punting the parameters off into their own ref-counted object, and forgoing all the copying.

[Gavin Barraclough]

Created attachment 38523 [details]
The Patch

[Gavin Barraclough]

Created attachment 38524 [details]
PassRefPtr != RefPtr

[Darin Adler]

Comment on attachment 38524 [details]
PassRefPtr != RefPtr

> +    finishParsing(adoptRef(new FunctionParameters(firstParameter)), ident);

The usual idiom would be to make a create function instead of doing the adoptRef here. I'd prefer to see it done that way.

I'd like to see the same thing for FunctionExecutable too; lets keep those adoptRef inside create functions, and keep the constructors private.

> +        void finishParsing(PassRefPtr<FunctionParameters> parameters, const Identifier& ident);

You could omit both of these argument names.

>  FunctionExecutable::~FunctionExecutable()
>  {
> -    for (int i = 0; i < m_parameterCount; ++i)
> -        m_parameters[i].~Identifier();
> -    fastFree(m_parameters);
>      delete m_codeBlock;
>  }

Seems like we should use OwnPtr for m_codeBlock.

> +    return adoptRef(new FunctionExecutable(functionName, body->source(), body->usesArguments(), body->parameters(), body->lineNo(), body->lastLine()));

See above comment about create.

r=me

[Gavin Barraclough]

Fixed all review comments except the OwnPtr one.

The problem here is that CodeBlock includes Executable, not vice-versa.  Every CodeBlock has a pointer to its owner Executable, and contains inline methods that access the it.  The OwnPtr template is not satisfied by a forward declaration of the CodeBlock types, so manual deletion seemed the simplest solution.

(Though any suggestions as to how this can be resolved would be welcomed.)

Sending        JavaScriptCore/ChangeLog
Sending        JavaScriptCore/bytecompiler/BytecodeGenerator.cpp
Sending        JavaScriptCore/bytecompiler/BytecodeGenerator.h
Sending        JavaScriptCore/parser/Nodes.cpp
Sending        JavaScriptCore/parser/Nodes.h
Sending        JavaScriptCore/runtime/Executable.cpp
Sending        JavaScriptCore/runtime/Executable.h
Transmitting file data .......
Committed revision 47775.

[Eric Seidel (no email)]

Looks like this caused:
	ecma/Date/15.9.5.12-1.js

to fail on the bots.  I'll re-open this for now in case we decide to roll this out.

[Eric Seidel (no email)]

I guess the test got fixed later, since I see no indication of this being rolled out.  closing again.