On Jun 19, 9:28 am, "Ruland Kevin-BHP637" <[EMAIL PROTECTED]>
wrote:
> I ran this through jprofiler and found some blockage.
>
> Here's a short list:
>
> During Startup the following show up:
> ScriptRuntime.initStandardObjects( Context, ScriptablObject, boolean )
> NativeGlobal.init(Context, Scriptable, boolean)
> NativeArray.<init>(long)
> NativeDate.<init>() -- in TimeZone.getDefault() actually.
> NativeIterator.init(ScriptableObject, boolean)
> ContextFactory.isDom3Present() -- Kit.classOrNull(String) --
> j.lang.forName(String)
> ContextFactory.getE4xImplementationFactory()
>
> Then during execution of the loops:
>
> Context.compileImpl(Scritpable,Reader,String,String,int,Object,boolean,E
> valuator,ErrorReporter)
> CompilerEnvirons.<init>()
> Parser.parse(String,String,int)
> TokenStream.<init>(Parser,Reader,String,int)
> Parser.createDecompiler(CompilerEnvirons)
> Parser.parse()
> Codegen.transform(ScriptOrFnNode)
> NodeTransformer.transformCompilationUnit(ScriptOrFnNode);
>
> Codegen.compileToClassFile(CompilerEnvirons,String,ScriptOrFnNode,String
> ,boolean)
> Codegen.generateCode(String) ==
> ClassFileWriter.<init>(String,String,String)
> ConstantPool.<init>(ClassFileWriter)
>
> There are many others. One notable is:
> DefiningClassLoader.loadClass(String,boolean) --
> j.lang.ClassLoader.loadClass(String) which is, I think, when rhino loads
> the compiled class for execution.
>
> I changed the example by naming the scripts uniquely per thread by
> changing one line of code:
>
> Script script = cx.compileString("new Date()",
> Thread.currentThread().getName(),0,null);
>
> Visual inspection of the blocking shows this is better behaved. Perhaps
> Rhino should do something smarter when the script name is null?
>
> I am confused by the contention during startup. I would not have
> expected there to be so much contention, I suspect its all in
> sealObject.
>
> Kevin
>
> -----Original Message-----
> From:
>
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> lla.org] On Behalf Of [EMAIL PROTECTED]
> Sent: Thursday, June 19, 2008 3:54 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Mozilla rhino performance issues under multithreads
> environment
>
> I took a thread dump. But, unlucky, I cannot see any "wait at ..monitor"
> message.
>
> There should have something blocked threads running!!!
>
> Anybody could help me?
>
> _______________________________________________
> dev-tech-js-engine-rhino mailing list
> [EMAIL PROTECTED]://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
If your performance model is really to compile scripts extremely
often, you should use interpreted mode rather than compiled mode. As
noted above, compiled mode implies Java classfile loading and is much
more heavyweight than interpreted mode. I wouldn't be surprised if
Java's loading of classes contains some locks that this test hits.
Alternatively, if you can compile scripts once and run multiple times
then compiling will likely pay off.
I don't understand how naming the scripts uniquely per thread would
make any difference to performance. This name is just used for error
messages and for debug information, as far as I can recall.
--N
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
