On 03/12/2015 09:41 PM, Roger Riggs wrote:
Hi Peter,
Introducing a public Process subtype would not be a binary compatible
change;
the return type of ProcessBuilder.start can not be narrowed.
As you surmised, a different start method would be needed on
ProcessBuilder.
Since ProcessBuilder i
On 03/12/2015 09:49 PM, Alan Bateman wrote:
On 05/03/2015 13:46, Chris Hegarty wrote:
:
Example:
class Stamp implements Serializable {
private transient final long millis;
Stamp() { millis = System.currentTimeMillis(); }
public long stamp() { return millis; }
Switches currently don't profile well (if at all) - John can shed more
light on that as this came up on the compiler list a few weeks ago.
sent from my phone
On Mar 12, 2015 6:06 PM, "Peter Levart" wrote:
>
>
> On 03/12/2015 10:04 PM, Peter Levart wrote:
>
> ... putLongUnaligned in the style of
On 03/12/2015 10:04 PM, Peter Levart wrote:
... putLongUnaligned in the style of above getLongUnaligned is more
tricky with current code structure. But there may be a middle ground
(or a sweet spot):
public final void putLongUnaligned(Object o, long offset, long x) {
if (((int)
Is vectorization coming soon? AFAIK, only memory copies are vectorized
currently but not any arithmetic or the like.
sent from my phone
On Mar 12, 2015 5:06 PM, "Andrew Haley" wrote:
> On 03/12/2015 07:29 PM, Peter Levart wrote:
> > What about the following variant (or similar with ifs in case s
On 03/12/2015 10:05 PM, Andrew Haley wrote:
On 03/12/2015 07:29 PM, Peter Levart wrote:
What about the following variant (or similar with ifs in case switch is
sub-optimal):
public final long getLongUnaligned(Object o, long offset) {
switch ((int) offset & 7)
...
I tried tha
On 03/12/2015 08:29 PM, Peter Levart wrote:
On 03/12/2015 07:37 PM, Andrew Haley wrote:
On 03/12/2015 05:15 PM, Peter Levart wrote:
...or are JIT+CPU smart enough and there would be no difference?
C2 always orders things based on profile counts, so there is no
difference. Your suggestion
On 03/12/2015 07:29 PM, Peter Levart wrote:
> What about the following variant (or similar with ifs in case switch is
> sub-optimal):
>
> public final long getLongUnaligned(Object o, long offset) {
> switch ((int) offset & 7)
...
I tried that already, and it wasn't really any faste
On 05/03/2015 13:46, Chris Hegarty wrote:
:
Example:
class Stamp implements Serializable {
private transient final long millis;
Stamp() { millis = System.currentTimeMillis(); }
public long stamp() { return millis; }
private void readObject(java.io.Object
Hi Peter,
Introducing a public Process subtype would not be a binary compatible
change;
the return type of ProcessBuilder.start can not be narrowed.
As you surmised, a different start method would be needed on ProcessBuilder.
Since ProcessBuilder is the preferred mechanism to created processes,
On 03/12/2015 07:37 PM, Andrew Haley wrote:
On 03/12/2015 05:15 PM, Peter Levart wrote:
...or are JIT+CPU smart enough and there would be no difference?
C2 always orders things based on profile counts, so there is no
difference. Your suggestion would be better for interpreted code
and I gues
On 03/12/2015 07:16 PM, Vitaly Davidovich wrote:
Right, ok -- just wanted to make sure I wasn't missing something. For
platforms that don't support unaligned access, is it expected that
callers will be reading/writing addresses that are unaligned to the
size of the type they're reading? My h
On 03/12/2015 05:15 PM, Peter Levart wrote:
> ...or are JIT+CPU smart enough and there would be no difference?
C2 always orders things based on profile counts, so there is no
difference. Your suggestion would be better for interpreted code
and I guess C1 also, so I agree it is worthwhile.
Thanks
On 03/12/2015 04:52 PM, Peter Levart wrote:
> ...getFloat() is calling getFloat(int) which is a virtual method with 2
> implementations. I think it would be better to in-line the the call and
> eliminate the need to execute checkIndex()...
Okay; I guess it is more symmetrical that way. I did ha
Right, ok -- just wanted to make sure I wasn't missing something. For
platforms that don't support unaligned access, is it expected that callers
will be reading/writing addresses that are unaligned to the size of the
type they're reading? My hunch is that on such platforms folks would tend
to alig
On 03/12/2015 06:30 PM, Vitaly Davidovich wrote:
Isn't the C2 intrinsic just reading the value starting at the
specified offset directly (when unaligned access is supported) and not
doing the branching?
It is. This code is for those platforms not supporting unaligned accesses.
Peter
On T
Isn't the C2 intrinsic just reading the value starting at the specified
offset directly (when unaligned access is supported) and not doing the
branching?
On Thu, Mar 12, 2015 at 1:15 PM, Peter Levart
wrote:
>
>
> On 03/10/2015 08:02 PM, Andrew Haley wrote:
>
> The new algorithm does an N-way bra
On 03/10/2015 08:02 PM, Andrew Haley wrote:
The new algorithm does an N-way branch, always loading and storing
subwords according to their natural alignment. So, if the address is
random and the size is long it will access 8 bytes 50% of the time, 4
shorts 25% of the time, 2 ints 12.5% of the
On 03/11/2015 06: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
(Answered.)
http://cr.openjdk.java.net/~ap
On Mar 12, 2015, at 1:07 PM, Chris Hegarty wrote:
>
I am pondering adding an api note to the count methods to head off any
suprises as now the stream pipeline may not be executed.
>>>
>>> I think it would be good to add a note to the spec, as this could be
>>> surprising.
>>>
>>> So
On Mar 12, 2015, at 5:06 AM, Alan Bateman wrote:
> If put throws IAE for an invalid key name then having get and remove do the
> same would be consistent. As the NUL case is a corner case and preferences
> don't seem to be widely used then I would think the compatibility impact of
> the IAE i
On 03/12/2015 02:39 PM, Roger Riggs wrote:
Hi,
Just a thought, it might be useful to introduce a public subtype of
Process that is
returned from ProcessBuilder for which the guarantees about behavior
could be
tighter (no UOEs). It would also provide a place to document the
behaviors
now sp
On 03/12/2015 03:10 PM, Chris Hegarty wrote:
>...but there is no ProcessHandle.onExit() (there is a
ProcessHandle.completableFuture()). Looks like Process and ProcessHandle are from
different stories?
I think you must be suffering from browser cache issues? I don’t see these
problems.
Indee
On 2015-03-10 08:53, Dmitry Samersoff wrote:
David at all,
May I consider the fix as reviewed and continue with integration?
Dmitry,
If you fix this, maybe you can also have a look at
https://bugs.openjdk.java.net/browse/JDK-8074839? Basically, at this
point, it would just be about verifyin
On 12 Mar 2015, at 13:56, Peter Levart wrote:
> On 03/11/2015 08:58 PM, Roger Riggs wrote:
>> Hi,
>>
>> The recommendations have been applied to the javadoc and the sandbox
>> JDK-8046092-branch.
>>
>>http://cr.openjdk.java.net/~rriggs/ph-apidraft/
>
> That's strange. Process no longer ex
Hi Peter,
On 3/12/2015 9:56 AM, Peter Levart wrote:
On 03/11/2015 08:58 PM, Roger Riggs wrote:
Hi,
The recommendations have been applied to the javadoc and the sandbox
JDK-8046092-branch.
http://cr.openjdk.java.net/~rriggs/ph-apidraft/
That's strange. Process no longer extends ProcessHand
On 03/11/2015 08:58 PM, Roger Riggs wrote:
Hi,
The recommendations have been applied to the javadoc and the sandbox
JDK-8046092-branch.
http://cr.openjdk.java.net/~rriggs/ph-apidraft/
That's strange. Process no longer extends ProcessHandle (which is
visible in apidraft), but ProcessHan
Hi,
Just a thought, it might be useful to introduce a public subtype of
Process that is
returned from ProcessBuilder for which the guarantees about behavior
could be
tighter (no UOEs). It would also provide a place to document the
behaviors
now spread across ProcessBuilder and Process.
$.0
Seems reasonable since the choice of threads that are used to achieve
the async behavior
is an (undocumented) implementation detail.
On 3/12/2015 9:09 AM, Chris Hegarty wrote:
This is looking good, still looking at the detail… just a quick comment.
It may be possible to remove the UOE from Pro
This is looking good, still looking at the detail… just a quick comment.
It may be possible to remove the UOE from Process.onExit, if you implement the
“never to be used” default without using ProcessHandle?
diff --git a/src/java.base/share/classes/java/lang/Process.java
b/src/java.base/share/
On 12 Mar 2015, at 11:25, Paul Sandoz wrote:
>
> On Mar 12, 2015, at 12:05 PM, Chris Hegarty wrote:
>
>>
>> On 12 Mar 2015, at 09:44, Paul Sandoz wrote:
>>
>>>
>>> On Mar 11, 2015, at 1:45 PM, Aggelos Biboudis wrote:
>>>
Hi all,
Please review the patch for the count termi
On 11/03/2015 18:25, Brian Burkhalter wrote:
Hello,
This message is a mere reprise of this reminder
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031848.html
from February 25. The original review thread on this topic went through to its
conclusion but some alternatives ar
On Mar 12, 2015, at 12:05 PM, Chris Hegarty wrote:
>
> On 12 Mar 2015, at 09:44, Paul Sandoz wrote:
>
>>
>> On Mar 11, 2015, at 1:45 PM, Aggelos Biboudis wrote:
>>
>>> Hi all,
>>>
>>> Please review the patch for the count terminal operator on SIZED streams.
>>>
>>> https://bugs.openjdk.j
On 03/12/2015 11:00 AM, Paul Sandoz wrote:
> We can re-use this one:
>
> https://bugs.openjdk.java.net/browse/JDK-8026049
Will do, thx.
Andrew.
On 12 Mar 2015, at 09:44, Paul Sandoz wrote:
>
> On Mar 11, 2015, at 1:45 PM, Aggelos Biboudis wrote:
>
>> 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/jd
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
>>
>> (Answered.)
On Mar 11, 2015, at 7:23 PM, Andrew Haley wrote:
> 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.
>
Ok. There are Unsafe tests in:
hotspot/test/runtime/
On Mar 11, 2015, at 1:45 PM, Aggelos Biboudis wrote:
> 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 Pau
Hello,
This message is a mere reprise of this reminder
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031848.html
from February 25. The original review thread on this topic went through to its
conclusion but some alternatives arose and there has been no definitive
outcome.
We can/should/will do it.
-Sherman
On 03/10/2015 11:39 AM, Viswanathan, Sandhya wrote:
Yes, it will be nice if the OpenJDK and Oracle builds for Linux/Solaris used
the system rather than
the bundled zlib. In which case, there will be no need for JVM command line
option. Also the HW/SW
compres
Hi Peter,
On 3/10/2015 12:47 PM, Peter Levart wrote:
On 03/10/2015 02:55 PM, Roger Riggs wrote:
ProcessHandle is designed to not to have an external implementations
(the constructor is package private).
I don't see a purpose in this. You can still subclass it freely,
because you can subclas
Hi,I've noticed something odd in the JDK8 source code. I've asked the question
on StackOverflow in the hope someone could answer, but it seems like no one is
able to give me the right answer.However, since the question interested me a
lot and seemed to interest a lot of people (as you can see on
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 the PID (parent,
On 03/10/2015 02:55 PM, Roger Riggs wrote:
ProcessHandle is designed to not to have an external implementations
(the constructor is package private).
I don't see a purpose in this. You can still subclass it freely, because
you can subclass Process which is-a ProcessHandle. I think it can be a
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 the
PID (parent, children, allChildren, info, compareTo). That effectively renders
Proce
45 matches
Mail list logo
