Jump to content
Excelsior Forums
Sign in to follow this  
rracaru

Escape analysis

Recommended Posts

Hi,

I saw a mention of the fact that Jet can remove locking operations on objects that don?t escape the current thread like:

class c

{

String test()

{

StringBuffer b = new StringBuffer();

b.append("local buffer");

return b.toString();

}

}

}

But looking at the asm code generated I see that the locking is still present, can you please explain in what conditions this optimization is done?

Thanks,

Radu

Share this post


Link to post
Share on other sites

Hello,

I have compiled the example with JET4.1 and I see that calls to StringBuffer constructor and 'append' were inlined to test() and synchronization locks were removed.

I wonder what version of JET are you using?

What options are set to compile the example ( "inline", "genstackalloc")?

What utility are you using to generate ASM code?

What kind of locks are there?

Anastasia.

Share this post


Link to post
Share on other sites

It works, impresive!

I had -genstackalloc- in the project config. For the asm output I use -genasm+.

It's there a reason for removing -checkindex- -checknull- -checkarrstore- options from the compiler?

Thanks,

Radu

Share this post


Link to post
Share on other sites

Hello,

The mentioned options are removed because they do not comply with the Java Specification.

You may consider it as a side effect of certifying our product Java Compatible :)

BTW, why do you need these options? We consider them unsafe.

Anastasia.

Share this post


Link to post
Share on other sites

Hi,

Yes I understand.

They are nice to have for just in case scenarios where you need an extra 15% - 20% precent boost in performance. Jet does not always removes all the checks even it they are safe to remove.

Speaking about performance, do you have any plans to intrisify the code for nio bytebuffer?

I'm evaluating your product and so far I'm pleased with what I've seen ,keep up the good work!

Share this post


Link to post
Share on other sites
Speaking about performance, do you have any plans to intrisify the code for nio bytebuffer?

Just now, we have no plans to do it. However if we find a real world benchmark where nio bytebuffer would be proven to be performance bottleneck, then it is possible for us to implement this.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×