Skip to main content

Performance

3 replies [Last post]
teilo
Offline
Joined: 2004-02-02

It's nice to see that the hotspot guys put a lot of effort into squeezing as much performance as they can out of the VM.

It's however a really shame when the library guys kill of any chance that the actual implementation (VM + libraries) will give any performance increase. (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6219959)

Does anyone except the hotspot people test and optimize their code?

Can we expect an optimized set of libraries as well as a VM for mustang?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
subanark
Offline
Joined: 2004-11-26

This problem and others can be solved with the proposial I made (and am working on) for constant variables and methods. An extreme use of this approach would allow String itself to be modified without causing any incompadiblities. And getting a (possibly) direct reference to String's char[] provided that the String uses it's entire char[].
This is what the decleration would look like:
[code]
@Constant
public final class String
{
@Cached private int hash = 0;
@Constant int pos;
/*Could be public.*/
@Constant int len;
char[] chars;

@Unitilized
public String(int len)
{
pos = 0;
this.len = len;
chars = new char[len];
}
@ConstantReturn
@Initilized
public char[] getConstChars()
{
if(pos == 0 && len == chars.length)
return chars;
else
return toCharArray();
}

@NonExternalReturn
public char[] toCharArray()
{...}

@Unitilized
public void setChar(char c,int index)
{
chars[index] = c;
}

/*toString requires that it be initlized String, since it
returns an initilized String*/
@Initilized
public String toString()
{
return this;
}

/*special semantics for cached value*/
@Initilized
@CacheInitliizer("hash")
public int hashcode()
{
if(hash == 0)
{
...
hash = ...;
}
return hash;
}
}
[/code]
The main reason that this would be safe is that unitlizied objects must remain in the locals or stack in exactly one thread. And the semantics only allow the object to be initlized in at one frame (usually the one that used new on the object). Similar classes could be made without having to do as much defensive programming.

mthornton
Offline
Joined: 2003-06-10

The buffer sharing used in previous JDKs gave rise to a number of performance related issues. The new code avoids these, at the expense of decreased performance for some code such as yours. It is much easier for you to regain your previous performance than it would have been to devise other fixes for the shared buffer problems.
Sometimes there isn't a pain free fix.

teilo
Offline
Joined: 2004-02-02

Well (in most cases) there was already a simple workaround for the memory leak - call trimToSize before toString;

I can't override StringBuffer/StringBuilder to provide a workaround of caching a return from toString and nulling it on any append etc. as both classes are final..