> On Apr 29, 2016, at 8:35 AM, Daniel Fuchs wrote:
>
> Hi Aleksey,
>
> On 29/04/16 12:12, Aleksey Shipilev wrote:
>> On 04/29/2016 01:05 PM, David Holmes wrote:
>>> On 29/04/2016 7:50 PM, Aleksey Shipilev wrote:
On 04/29/2016 02:09 AM, David Holmes wrote:
> This change is small in natu
> On Apr 29, 2016, at 5:12 AM, Aleksey Shipilev
> wrote:
>
>> On 04/29/2016 01:05 PM, David Holmes wrote:
>>> On 29/04/2016 7:50 PM, Aleksey Shipilev wrote:
On 04/29/2016 02:09 AM, David Holmes wrote:
This change is small in nature but somewhat broad in scope. It "affects"
the im
Hi Tom,
Some background on some observations and strategies folks have tended to take
wrt GC tuning.
With both Parallel GC and CMS GC, a common approach by folks tuning GC and heap
sizes is to employ a strategy of promoting as few objects as possible from
young generation to old generation. In
Potentially in the future. It has been on a list of candidate enhancements for
quite some time.
As Aleksey just mentioned in his response, (he beat me to the punch), that work
is not in scope as part of this project.
Should also mention that the work from this project would not prohibit such an
return a unique object!
Martin
On Mon, Jun 9, 2008 at 11:26 AM, charlie hunt <[EMAIL PROTECTED]> wrote:
Martin,
I'm rather shocked at your response!
Consider for example, there's a very popular tool out their that integrates
very well into NetBeans IDE and Eclipse IDE w
roven to not tell the
difference), and there are sufficient
regression tests to keep all of us in line.
Martin
On Mon, Jun 9, 2008 at 7:57 AM, charlie hunt <[EMAIL PROTECTED]> wrote:
wrt the Integer & Long values you use in your test case ...
You might consider using larger
ot;\n==> " + m.getClass().getName());
@@ -572,6 +593,7 @@ public class MOAT {
}
if (supportsPut(m)) {
+testPutPreversesObjectIdentity(m);
try {
check(m.put(, 77777) == null);
check(m.put(9134, 74982) == null);
--
Charlie Hunt
Java Performance Engineer
<http://java.sun.com/docs/performance/>
Looks like TreeMap.NavigableSubMap.entrySetView is initialized to null,
but it is never updated when an "entry set view" is created by
TreeMap.AscendingSubMap.entrySet() or by
TreeMap.DescendingSubMap.entrySet().
I think those two methods were intended to be implemented as:
For AscendingSubMa
map has been created.
Martin
On Fri, May 23, 2008 at 6:36 PM, charlie hunt <[EMAIL PROTECTED]> wrote:
If that's the definition given to "restricted range", I think there is some
inconsistencies in the behavior of TreeMap.
If you play around with some of descendingMap(), sub
the elements that it currently contains.
This may not be described in the clearest way in the doc,
but I'm not motivated to work on clarifying it,
partly because I've generally felt it was a design mistake
to try to enforce these kinds of range restrictions,
although I helped to impleme
tion expected behavior? Or, is this indeed a defect?
Attached is a simple program which illustrates what I have described.
thanks,
charlie ...
--
Charlie Hunt
Java Performance Engineer
<http://java.sun.com/docs/performance/>
import java.util.NavigableMap;
import java.util.Sort
Alan Bateman wrote:
Martin Buchholz wrote:
:
2. Bug creation from Charlie (or some other person empowered to do so)
I suggest making this bug P2-S2.
I will need the bug id and synopsis to create the proper mercurial
comment.
I don't know if Charlie is online today, but as you seem to be re
tin
On Fri, Apr 18, 2008 at 2:39 PM, kevin bourrillion <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Wow. TreeMap.java line 1024:
return new DescendingKeyIterator(getFirstEntry());
Sure does look fishy.
On Thu, Apr 17, 2008 at 2:54 PM, charlie hunt
Been looking at TreeMap's implementation rather closely and observed
something I don't understand. %-)
TreeMap (as of JDK 6 and later) implements NavigableMap. NavigableMap
requires an implementation of a navigableKeySet() method which returns a
NavigableSet. So, in TreeMap I see:
public
It's likely what you are observing in #2 & #3 and possibly in #1 also is
an artifact of inlining and possibly other JIT (dynamic) compiler
optimizations.
You might consider re-running your experiment with inlining disabled,
-XX:-Inlining.
Or, alternatively try running your experiment (with i
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Charlie Hunt
Java Performance Engineer
<http://java.sun.com/docs/performance/>
16 matches
Mail list logo
