Changeset: 7292cff45988
Author:erikj
Date: 2012-02-22 09:24 +0100
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7292cff45988
7141244: build-infra merge: Include $(SPEC) in makefiles and make variables
overridable
Reviewed-by: dholmes, ohrstrom, ohair, jcoomes
!
This a simple fix to solve CR 6988220:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6988220
The use of String.intern() in the ObjectName class prevents
the class the scale well when more than 20K ObjectNames are
managed. The fix simply removes the use of String.intern(),
and uses regular
On 22 feb 2012, at 11:22, A. Sundararajan wrote:
SA uses stop-the-world to debug snapshot of the process. BugSpot was
supposed to be a SA model where you can pause/resume and keep looking at
different snapshots (as well as use JDI to look at process state). But, it
was never implemented
I think current SA/hotspot developers are the best judges. I used to be
part of serviceability team and worked on SA among other things in the
past. AFAIK, SA suspend/resume was never really implemented or worked
properly. If that is still thought to be useful, we may to see if we can
Hi Staffan,
So maybe CLHSDB can be improved and JSDB retired?
Maybe, if the input experience of CLHSDB can be improved. It's awful to
prototype new commands with JavaScript in CLHSDB, because the whole snippet
of script is only allowed to span one single line, using jseval. If it
can at least
No particular reason. But after thinking more about it,
equals() should be a better choice, clearer code, and
the length check in equals() implementation is likely
to help performance of ObjectName's comparisons as
ObjectNames are often long with a common section at the
beginning.
I've updated
Changeset: 3ad851a7e884
Author:darcy
Date: 2012-02-23 09:53 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3ad851a7e884
7148025: javac should not warn about InterrupttedException on the declaration
of AutoCloseable itself
Reviewed-by: mcimadamore
!
Hi Fred,
java.lang.ObjectName? :) Need to fix that.
So often we intern strings precisely so that equals() can use == to
improve performance.
It seems to me that this is a case of fixing something for one
use-case without knowing what the impact will be on other use-cases!
Is there perhaps
Making String.intern() more scalable has been on our list of
things-to-do for a long, long time. But, it's not trivial. Simply
increasing the size of the hashtable is no good because we'd be upping
our footprint unconditionally, so really we want a growing hashtable
which is a bit more
Hi Keith,
Another problem with using 'intern()' is that when you intern a string
you're placing it into the permgen, and space there is at a premium. (no
perm gen project will hopefully fix this soon).
Actually that's fixed already, in 6962931 and a couple of related fixes
later.
- Kris
On
Hi Frederic,
Performance and typo comments.
Regarding performance of ObjectName.equals method, which is certainely
a frequent call on ObjectNames, I think that using inner fields
(Property array for canonical name and domain length) would be more
efficient
than using String.equals() on these
Hi Frederic,
Just curious - why are you checking string equality via compareTo() instead
of equals()?
Thanks
Sent from my phone
On Feb 23, 2012 10:37 AM, Frederic Parain frederic.par...@oracle.com
wrote:
This a simple fix to solve CR 6988220:
12 matches
Mail list logo
