Re: (S) RFR: 8154710: [Solaris] Investigate use of in-memory low-resolution timestamps for Java and internal time API's

> 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: >

Re: (S) RFR: 8154710: [Solaris] Investigate use of in-memory low-resolution timestamps for Java and internal time API's

> 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

Re: RFR(s): 6764713: Enlarge the age field in object headers to allow a higher MaxTenuringThreshold

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.

Re: More memory-efficient internal representation for Strings: call for more data

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

minor bug, TreeMap.NavigableSubMap.entrySetView usage

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

Re: more TreeMap questions (descendingMap, headMap and tailMap)

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(), subMap(), headMap() and tailMap() variations

more TreeMap questions (descendingMap, headMap and tailMap)

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.SortedMap; import java.util.TreeMap; public class TestTreeMap { private

Re: TreeMap.navigableKeySet().descendingIterator() sequence ?

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 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Been looking

TreeMap.navigableKeySet().descendingIterator() sequence ?

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 NavigableSetK. So, in TreeMap I see:

Re: encoding-agnostic byte[]-based regexp engine...interested?

] For additional commands, e-mail: [EMAIL PROTECTED] -- Charlie Hunt Java Performance Engineer http://java.sun.com/docs/performance/