On 10/03/2015 3:04 PM, Martin Buchholz wrote:
??
I mentally map Java volatile operations to C11 seq_cst because of the
total order over all operations on volatile variables.
Volatile reads and writes do not just have acquire/release semantics.
You may be right. The synchronization order (not ju
??
I mentally map Java volatile operations to C11 seq_cst because of the total
order over all operations on volatile variables.
Volatile reads and writes do not just have acquire/release semantics.
The java memory model does not (yet) have C11-style relaxed atomics (like
acquire or release)
On Mon
PS. You state: "Corresponds to C11 atomic_compare_exchange_strong." Yet
that would match with the full bi-directional fences of the VM
implementation (due to memory_order_seq_cst), not a volatile read
followed by a volatile write (which would be memory_order_acq_rel).
http://en.cppreference.co
On 10/03/2015 2:21 AM, Martin Buchholz wrote:
On Mon, Mar 9, 2015 at 4:13 AM, David Holmes mailto:david.hol...@oracle.com>> wrote:
On 9/03/2015 7:27 PM, Andrew Haley wrote:
But who is to say that is the specification for the Unsafe API?
It's for us to say!
I meant specifically the
On Mon, Mar 9, 2015 at 3:22 PM, Xueming Shen
wrote:
> The result looks good, though I doubt it will bring in any real
> "meaningful" performance
> improvement when reading a zip/jar file. But faster is faster.
>
You're right - it will make a 20% improvement in something that is only a
small par
The result looks good, though I doubt it will bring in any real "meaningful"
performance
improvement when reading a zip/jar file. But faster is faster. The same
improvement might
not applied to the java version, given those range check?
-Sherman
On 03/09/2015 01:14 PM, Martin Buchholz wrote:
Hi Ivan,
I really appreciate you and others for proactively contributing to the
jaxp code. Unfortunately, I have to say sorry that it may be not
feasible to apply this patch. The reason is that the patch covers just
the BCEL component, but the upstream source had been updated already.
The pr
On 09/03/2015 19:47, Roger Riggs wrote:
Please review this update to specify that ProcessBuilder methods throw
NullPointerException
when arguments are null. The implementation behavior is unchanged and
correct
but the specification of NPE is missing for methods redirectInput,
redirectOutput, a
Perhaps I shouldn't have tried to do anything on this front, given the
cross-system difficulties that especially David has battled for years. I'm
surprised Aleksey is not a fan - I expected Aleksey to want a version of
nanoTime more suitable for benchmarking.
I learned about the various "clocks"
I actually benchmarked my last suggestion to be 20% faster on an ad-hoc
microbenchmark. We can go faster yet on x86 if we use unaligned 4-byte
uint32 reads. Maybe in a future change.
In general, hardware is moving in the direction of allowing unaligned reads
without performance penalty, especial
Seems alright.
On Mon, Mar 9, 2015 at 12:47 PM, Roger Riggs wrote:
> Please review this update to specify that ProcessBuilder methods throw
> NullPointerException
> when arguments are null. The implementation behavior is unchanged and
> correct
> but the specification of NPE is missing for meth
Please review this update to specify that ProcessBuilder methods throw
NullPointerException
when arguments are null. The implementation behavior is unchanged and
correct
but the specification of NPE is missing for methods redirectInput,
redirectOutput, and redirectError.
The choice of a singl
Hi Jason,
Comparing with startInstant is a possibility, assuming it is cached in
the ProcessHandle
and increases the cost of creating ProcessHandles since it needs to be
parsed from /proc files.
And it can help a long standing potential issue of pid's being re-used.
ProcessHandle is only withi
On Mar 9, 2015, at 6:09 PM, Andrew Haley wrote:
> On 03/09/2015 04:59 PM, Paul Sandoz wrote:
>>
>> On Mar 9, 2015, at 5:04 PM, Andrew Haley wrote:
>>
>>> On 03/09/2015 03:10 PM, Paul Sandoz wrote:
Do you want to tackle the single-address access methods as a follow up
issue?
>>>
>>
On 3/9/2015 4:36 AM, Paul Sandoz wrote:
On Mar 9, 2015, at 9:41 AM, Amy Lu wrote:
Please review the fix for Doclint regression in java/util/regex/Matcher.java:
error: bad use of '>'
from
* mr -> mr.group().toUpperCase(), an invocation of this method on
This fixed by using @code tag
Works for me till we figure it out
On Mar 9, 2015, at 1:56 PM, joe darcy wrote:
> Hello,
>
> In some internal test runs, we're seeing intermittent test failures of the
> javax/xml/jaxp/testng/validation tests when run in jtreg with high
> concurrency. While some underlying issues are investig
Hello,
In some internal test runs, we're seeing intermittent test failures of
the javax/xml/jaxp/testng/validation tests when run in jtreg with high
concurrency. While some underlying issues are investigated, I'd like to
add the javax/xml/jaxp/testng/validation directory to the list of
direc
On 03/09/2015 04:59 PM, Paul Sandoz wrote:
>
> On Mar 9, 2015, at 5:04 PM, Andrew Haley wrote:
>
>> On 03/09/2015 03:10 PM, Paul Sandoz wrote:
>>> Do you want to tackle the single-address access methods as a follow up
>>> issue?
>>
>> It's not clear to me that we need any single-address access
On Mar 9, 2015, at 5:04 PM, Andrew Haley wrote:
> On 03/09/2015 03:10 PM, Paul Sandoz wrote:
>> Do you want to tackle the single-address access methods as a follow up issue?
>
> It's not clear to me that we need any single-address access methods
> because we can pass in a null object. Personal
Anything but allowing UOE to escape compareTo sounds good.
Apologies if I missed this in previous threads but, shouldn't
ProcessHandle.compareTo compare hostname, startInstant, and then pid? Or
assuming they are not comparable between hosts then just startInstant and pid.
Jason
--
On Mon, Mar 9, 2015 at 4:13 AM, David Holmes
wrote:
> On 9/03/2015 7:27 PM, Andrew Haley wrote:
>
>>
>> But who is to say that is the specification for the Unsafe API?
It's for us to say!
> The public API's have a specification for what they provide to the
> programmer. On what basis are we a
On 03/09/2015 03:10 PM, Paul Sandoz wrote:
> Do you want to tackle the single-address access methods as a follow up issue?
It's not clear to me that we need any single-address access methods
because we can pass in a null object. Personally I would prefer that.
Thoughts?
Andrew.
On Mar 6, 2015, at 7:50 PM, Andrew Haley wrote:
> I've tried to so everything I've been asked. If this version passes
> muster with everyone I'll Javadoc all the public methods and fields
> and put it up for RFA next week.
>
Do you want to tackle the single-address access methods as a follow
On 09/03/15 14:28, Roger Riggs wrote:
Hi,
The problem could be isolated to compareTo by defining the ordering if
getPid
throws UOE and without diluting the spec for getPid returning the native
os process identifier.
Yes, that would work.
Defining the default for getPid() to return -1, might
Hi,
The problem could be isolated to compareTo by defining the ordering if
getPid
throws UOE and without diluting the spec for getPid returning the native
os process identifier.
Defining the default for getPid() to return -1, might not have too big
an impact.
It would order the incompletely
On 03/09/2015 11:32 AM, Peter Levart wrote:
> On 03/09/2015 10:11 AM, Andrew Haley wrote:
>> On 08/03/15 23:21, Remi Forax wrote:
>>> BE doesn't need to be an instance, method of Unsafe are instance methods
>>> just to enforce security,
>>> you can not call them if you don"t have an instance of Uns
On Mar 9, 2015, at 9:41 AM, Amy Lu wrote:
> Please review the fix for Doclint regression in java/util/regex/Matcher.java:
>
>error: bad use of '>'
>
> from
>* mr -> mr.group().toUpperCase(), an invocation of this method on
>
> This fixed by using @code tag
>
> bug: https://bugs.openj
On 03/09/2015 10:11 AM, Andrew Haley wrote:
On 08/03/15 23:21, Remi Forax wrote:
BE doesn't need to be an instance, method of Unsafe are instance methods
just to enforce security,
you can not call them if you don"t have an instance of Unsafe (and
getUnsafe() does the security check).
BE is priv
On 03/09/2015 11:13 AM, David Holmes wrote:
> On 9/03/2015 7:27 PM, Andrew Haley wrote:
>> On 09/03/15 00:34, David Holmes wrote:
>>> On 7/03/2015 6:49 AM, Martin Buchholz wrote:
A wee code review fer ya:
https://bugs.openjdk.java.net/browse/JDK-8074578
http://cr.openjdk.java.ne
On 9/03/2015 7:27 PM, Andrew Haley wrote:
On 09/03/15 00:34, David Holmes wrote:
On 7/03/2015 6:49 AM, Martin Buchholz wrote:
A wee code review fer ya:
https://bugs.openjdk.java.net/browse/JDK-8074578
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Unsafe-CAS-spec/
Sorry Martin but this
On 06/03/15 19:34, Jason Mehrens wrote:
Hi Chris,
Since getPid can throw UOE that means that compareTo could now throw UOE.
Ooh... I don't like this.
Has any consideration been given to getPid returning -1, if unknown or
the default implementation? Or would this be any better?
-Chris
On 09/03/15 00:34, David Holmes wrote:
> On 7/03/2015 6:49 AM, Martin Buchholz wrote:
>> A wee code review fer ya:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8074578
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Unsafe-CAS-spec/
>
> Sorry Martin but this is neither accurate nor meanin
On 08/03/15 23:21, Remi Forax wrote:
> BE doesn't need to be an instance, method of Unsafe are instance methods
> just to enforce security,
> you can not call them if you don"t have an instance of Unsafe (and
> getUnsafe() does the security check).
>
> BE is private so it doesn't have to be an i
Thanks, looks good!
/Erik
On 2015-03-06 17:14, Magnus Ihse Bursie wrote:
On 2015-03-04 14:31, Erik Joelsson wrote:
Hello,
Really nice to finally see this patch getting done!
Only one comment:
flags.m4:
In the grep expression, could you move the extra [] outside of the
actual command line o
On 08/03/15 23:04, Peter Levart wrote:
>
> On 03/08/2015 12:13 PM, Andrew Haley wrote:
>>> > That's OK if you think this approach is a better division of
>>> > concerns (Unsafe being low-level), but in Heap-X-Buffer you are only
>>> > using Unsafe.get|putXXXUnaligned() and don't consider using
>>>
Please review the fix for Doclint regression in
java/util/regex/Matcher.java:
error: bad use of '>'
from
* mr -> mr.group().toUpperCase(), an invocation of this
method on
This fixed by using @code tag
bug: https://bugs.openjdk.java.net/browse/JDK-8074674
webrev: http://cr.openjdk.ja
36 matches
Mail list logo
