Hi,
Here is an updated treatment of computeIfAbsent():
http://cr.openjdk.java.net/~bchristi/8071667/webrev.1/
There's a webrev, as well as built docs for Map[1], ConcurrentMap[2],
and HashMap[3] (and I now realize there should be Hashtable as well).
I've made use of @implSpec and friends in
Hi,
The recommendations have been applied to the javadoc and the sandbox
JDK-8046092-branch.
http://cr.openjdk.java.net/~rriggs/ph-apidraft/
Some operations on a Process take an extra dereference due to the
delegation to ProcessHandle.
For example, getting the cputime or startTime of th
On 03/11/2015 06:00 PM, Paul Sandoz wrote:
> We need to include some unit tests before we can push.
I have a test which I've been using. It could be converted into
a unit test.
Andrew.
Hi Andrew,
On Mar 11, 2015, at 6:27 PM, Andrew Haley wrote:
> On 03/11/2015 07:10 AM, John Rose wrote:
>>>
>>> John: I'm waiting for an answer to my question here before I submit
>>> a webrev for approval.
>>>
>>> http://mail.openjdk.java.net/pipermail/panama-dev/2015-March/99.html
>>
>>
On 03/11/2015 05:41 PM, Vitaly Davidovich wrote:
> I don't think we need this unalignedKnown dance anymore -- just return
> unsafe.unalignedAccess() there?
Yup.
Andrew.
Also,
static boolean unaligned() {
595 if (unalignedKnown)
596 return unaligned; 597 unaligned =
unsafe.unalignedAccess();
598 unalignedKnown = true;
599 return unaligned;
600 }
I don't think we need this unalignedKnown dance anymore -- just
On 03/11/2015 05:38 PM, Vitaly Davidovich wrote:
> private static final ByteOrder byteOrder
> 571 = unsafe.isBigEndian() ? ByteOrder.BIG_ENDIAN :
> ByteOrder.LITTLE_ENDIAN;
> 572
> 573 static ByteOrder byteOrder() {
> 574 if (byteOrder == null)
> 575 throw new
private static final ByteOrder byteOrder 571 =
unsafe.isBigEndian() ? ByteOrder.BIG_ENDIAN : ByteOrder.LITTLE_ENDIAN;
572
573 static ByteOrder byteOrder() {
574 if (byteOrder == null)
575 throw new Error("Unknown byte order");
576 return byteOrder;
577
On 03/11/2015 07:10 AM, John Rose wrote:
>>
>> John: I'm waiting for an answer to my question here before I submit
>> a webrev for approval.
>>
>> http://mail.openjdk.java.net/pipermail/panama-dev/2015-March/99.html
>
> (Answered.)
http://cr.openjdk.java.net/~aph/unaligned.jdk.5/
http://cr.op
Hi,
Also, is there a proposal for Process.compareTo?
It can be left out for the status quo, but otherwise the issue with
getPid()/toHandle and UOE remains.
Though the previously described artificial pid workarounds can be used.
Roger
On 3/11/2015 7:57 AM, Peter Levart wrote:
On 03/11/2015 1
Hi,
I think the 'convenience' methods for onExit() and getPid() are
useful/desirable on Process.
It should not be necessary to shuttle over to ProcessHandle to do basic
functions on the Process.
Roger
On 3/11/2015 7:34 AM, Peter Levart wrote:
On 03/11/2015 11:29 AM, Chris Hegarty wrote:
c
On Wed, Mar 11, 2015 at 7:19 AM, Andrew Haley wrote:
> Javadoc API seems to be descriptive:
>
> "Returns a string ...
> "Wakes up a single thread ...
> "Creates and returns ...
>
> But sometimes it's imperative:
>
> "Block current thread, returning when...
> "Report the scale...
> "Define a class
Javadoc API seems to be descriptive:
"Returns a string ...
"Wakes up a single thread ...
"Creates and returns ...
But sometimes it's imperative:
"Block current thread, returning when...
"Report the scale...
"Define a class...
Which is right?
Thanks,
Andrew.
Hi all,
Please review the patch for the count terminal operator on SIZED streams.
https://bugs.openjdk.java.net/browse/JDK-8067969
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8067969-optimize-stream-count/webrev/
Thanks Paul Sandoz for sponsoring this.
Kind regards,
Aggelos Biboudis.
On 03/11/2015 12:51 PM, Chris Hegarty wrote:
On 11/03/15 11:34, Peter Levart wrote:
On 03/11/2015 11:29 AM, Chris Hegarty wrote:
can be removed, no?
long getPID() throws USO { throw new USO; }
I think ProcessHandle needs a protected constructor, otherwise it
cannot be implemented outsid
On 11/03/15 11:34, Peter Levart wrote:
On 03/11/2015 11:29 AM, Chris Hegarty wrote:
can be removed, no?
long getPID() throws USO { throw new USO; }
I think ProcessHandle needs a protected constructor, otherwise it
cannot be implemented outside of the platform. Or is this the intent?
In w
On 03/11/2015 11:29 AM, Chris Hegarty wrote:
can be removed, no?
long getPID() throws USO { throw new USO; }
I think ProcessHandle needs a protected constructor, otherwise it
cannot be implemented outside of the platform. Or is this the intent?
In which case Process.getPid() may need to
On Mar 11, 2015, at 12:12 PM, Peter Levart wrote:
>>
>> CF onProcessExit() { ... } // crappy default
>
> I don't know. There are two ways to get that behaviour then.
> Process.onProcessExit() and Process.toHandle().onExit(). If Process is not a
> subtype of ProcessHandle, we can skip this
On Mar 11, 2015, at 11:29 AM, Chris Hegarty wrote:
>>
>> I still think that conflates the "OS says no" and the "Subtype of Process
>> does not support the contract of ProcessHandle".
>>
>> Process as designed feels kind of limited and we are stuck with that.
>> ProcessHandle is then also limit
On 03/11/2015 11:06 AM, Paul Sandoz wrote:
>In many cases already, if the OS does not provide values or the OS permissions
do not permit
>it then the values returned are empty (instead of throwing exceptions).
>That design can be extended to the external subclasses by specifying the
default beh
On 11/03/15 10:06, Paul Sandoz wrote:
On Mar 10, 2015, at 4:41 PM, Roger Riggs wrote:
Hi Paul,
On 3/10/2015 11:22 AM, Paul Sandoz wrote:
Any sub-type of Process that does not override getPid will essentially result
in that USO being propagated to many ProcessHandle methods that depend on
On Mar 10, 2015, at 8:06 PM, Martin Buchholz wrote:
> I agree with Andrew that the Unsafe API matters, and there are many
> implementations of it (even multiple within openjdk itself!).
>
> I still know of no reason why my proposed spec is wrong. If C11 support was
> good and ubiquitous, I w
On Mar 11, 2015, at 12:34 AM, Brent Christian
wrote:
> Hi, Paul
>
> On 3/10/15 8:29 AM, Paul Sandoz wrote:
>>
>> On the Map.compute* methods.
>>
>> Perhaps we can reuse similar language to that we added for Matcher:
>>
>> * The mapping function should not modify this map during computation.
On Mar 10, 2015, at 12:02 PM, Andrew Haley wrote:
>
> The new algorithm is slightly slower because of branch misprediction.
>
> old: 2.17 IPC, 0.08% branch-misses, 91,965,281,215 cycles
> new: 1.23 IPC, 6.11% branch-misses, 99,925,255,682 cycles
>
> ...but it executes fewer instructions so we
24 matches
Mail list logo
