antee, I might as well do my own "static final List
EMPTY = ...".
Thanks
Moh
>-Original Message-
>From: Brian Goetz [mailto:brian.go...@oracle.com]
>Sent: Tuesday, December 01, 2015 10:03 PM
>To: Stuart Marks; Rezaei, Mohammad A. [Tech]
>Cc: 'core-libs-dev&
Value based things make a lot of sense for types that don't belong to well
established reference hierarchies. I can even see great uses for a value based
List implementation, so long as it's preferentially referenced as the exact
type (e.g. private ValueBasedList someList = ...) and rarely cast
Can the Javadoc for of() (no args) be enhanced to spell out the cost/garbage
semantics? Collections.emptyList() does a great job of that:
* @implNote
* Implementations of this method need not create a separate List
* object for each call. Using this method is likely to have compa
>> Might the following be needed or not:
>>
>> Reference(T referent, ReferenceQueue queue) {
>> this.referent = referent;
>> this.queue = (queue == null) ? ReferenceQueue.NULL : queue;
>> reachabilityFence(referent);
>> }
>
queue is marked volatile, so a simple reor
Thread.yield(), Thread.sleep(), Thread.spinLoopHint()?
Somehow, it feels right (as in consistent), but also off at the same time (as
in, why are these on Thread).
I'd take consistent over bespoke-one-static-method-class, unless there was a
concerted effort to consolidate other related api/conce
The proposed API makes good sense for what I would consider coarse grained
cleanup.
There is another significant use case for Weak/Soft references that is not
covered here: weak/soft references used in cache like data structures, e.g.
WeakHashMap.
Wouldn't there be significant code reuse if I
d
confusion?
Thanks
Moh
>-Original Message-
>From: Peter Levart [mailto:peter.lev...@gmail.com]
>Sent: Monday, June 08, 2015 1:07 PM
>To: Rezaei, Mohammad A. [Tech]
>Cc: 'hotspot-gc-...@openjdk.java.net openjdk.java.net'; 'core-libs-
>d...@openjdk.java.net'
>S
Shouldn't we extend the same notion to other reference types? For Weak/Soft
references, the (rough) equivalent would be a method of the kind:
public void markUnqueueable() // suggestions for better method name most
welcome!
{
this.q = ReferenceQueue.NULL;
}
This is quite useful when the
ith meaningful numbers.
Thanks
Moh
From: Peter Levart [mailto:peter.lev...@gmail.com]
Sent: Monday, June 01, 2015 5:04 AM
To: Rezaei, Mohammad A. [Tech]
Cc: 'hotspot-gc-...@openjdk.java.net openjdk.java.net';
'core-libs-dev@openjdk.java.net'
Subject: Re: JEP 132: More-prom
The problems start with the ReferenceQueue object and the heavy synchronization
in it. Consider structures like j.u.WeakHashMap that need to expunge entries.
If such structures are made somewhat concurrent, the lock in ReferenceQueue
starts to become a serious problem:
- In structures
For what it's worth, I fully agree with David and Kirk around finalization not
necessarily needing this treatment.
However, I was hoping this would have the effect of improving (non-finalizable)
reference handling. We've seen serious issues in WeakReference handling and
have had to write some t
Stefan, you're looking at an older version of the code. If you apply Paul's
suggestions from
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-May/033640.html
the code works as expected.
Thanks
Moh
>-Original Message-
>From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.ja
We have a set of JMH tests. We'll work with Sunny to make those part of the
webrev (where do they go?) and the specific test you suggested below.
Thanks
Moh
>-Original Message-
>From: Paul Sandoz [mailto:paul.san...@oracle.com]
>Sent: Friday, May 22, 2015 4:02 AM
>To: R
Cc: Chan, Sunny [Tech]; O'Leary, Kristen [Tech]; Rezaei, Mohammad A. [Tech]
>Subject: Re: Patch to improve primitives Array.sort()
>
>Hi,
>
>I finally got some time to better understand the patch and more generally this
>area of code.
>
>I applied the patch and ran the
For what it's worth, we would welcome this change. We took a large memory hit
and a small performance hit when we upgraded from 1.6 to 1.7 in some of our
memory-bound applications.
>From a purely performance perspective, the most expensive CPU operations are
>memory access these days. Anything
Why do you expect the new classes in the JDK not to be part of the API? Simple
example:
I have a library that's 5 years old. The API needed the equivalent of
java.util.Function (from Java 8), which obviously was not there when I wrote my
library. Let's say I had defined CustomFunction and now I
16 matches
Mail list logo
