Skip to main content

[Regression] Very slow accessors

8 replies [Last post]
spdenne
Offline
Joined: 2006-02-15
Points: 0

I'm having some difficulty narrowing down a serious performance regression in Mustang that I've come across recently.

I took a look at an implementation of Knuth's dancing links algorithm. The core of the algorithm, which happens a lot, is essentially:

node.getLeft().setRight(node.getRight());
node.getRight().setLeft(node.getLeft());

to remove a node from a doubly linked list. The methods called couldn't be much simpler:

void setLeft(Node left) { this.left = left; }
Node getLeft() { return left; }
void setRight(Node right) { this.right = right; }
Node getRight() { return right; }

On my WinXP laptop, the algorithm finds roughly 90,000 solutions per second in Java 5, and about 45,000 solutions per second in Mustang b71.
That is with using -server
I see a similar speed difference in client mode (60,000 in Java 5, 30,000 in Mustang)

However, if I change just the accessors' access from friendly/package access to protected or public, then Mustang runs a few percent faster than Java 5.

void setLeft(Node left) { this.left = left; }
protected Node getLeft() { return left; }
void setRight(Node right) { this.right = right; }
protected Node getRight() { return right; }

My attempts at producing a small example to demostrate the problem never seem to run any slower in Mustang than in Java 5, so I'm posting here to see if anyone can confirm the regression.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
spdenne
Offline
Joined: 2006-02-15
Points: 0

Thanks Ross.

I've now made the jars demostrating this problem generally available at http://www.datacute.co.nz/dlx_regression.zip

rossk
Offline
Joined: 2006-02-02
Points: 0

A couple of guesses:
1) adding the protected attribute changed the field
layout in the object which then caused more cache
misses -- not much you can do about this
2) accessor inlining is not occurring in the slow case
Try rerunning the Mustang jvm with the following
option:
-XX:-UseFastAccessorMethods
There has been a problem reported with this flag.

Could you post a link to the jar file?

spdenne
Offline
Joined: 2006-02-15
Points: 0

1) The same object bytecode runs a different speed in Java 5 and Java 6... does Java 6 have a smaller cache? (It's adding the protected attribute which restores the expected speed, not slows it.)

2) -XX:-UseFastAccessorMethods does seem to make a difference, but still leaves a 20% speed decrease. Are there any public references to the reported problems with this flag? All I can find are Bug IDs 4395315 and 4293026

I've emailed the author of most of the code that I was using when I encountered this problem. The copyright statements in the source code would let me distribute it, but I'll await a reply from him.

rossk
Offline
Joined: 2006-02-02
Points: 0

Looks like a problem in the 6.0 jvm with identifying
single implementors which have default package visibility.
This problem is inhibitting the inlining of Node's get() accessors, causing the slow down. There's no current bug for this issue, so I'll construct a generic test case and file a new bug. I'll post the bugid tomorrow. Thanks for noticing and reporting this issue.

rossk
Offline
Joined: 2006-02-02
Points: 0

I've filed bug 6387299
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6387299

(May not be visible for a few hours.)

rossk
Offline
Joined: 2006-02-02
Points: 0

Repeating the above since it looks like the java.net
database is corrupted and change the poster from rossk
to Visual Paradigm (nice login, by the way.)

I've filed bug 6387299
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6387299

(May not be visible for a few hours.)

spdenne
Offline
Joined: 2006-02-15
Points: 0

This is fixed in build 79, but it is missing from the list of bugs fixed in the build.
https://mustang.dev.java.net/files/documents/2817/32495/mustang-b79.html

rasbold
Offline
Joined: 2005-06-21
Points: 0

I'm trying to find out why 6387299 wasn't listed on the fixed bug list for b79.

Sorry about that. Please bear with us.