On 10 Feb 2015, at 12:46, Paul Sandoz paul.san...@oracle.com wrote:
Hi David,
On Feb 10, 2015, at 1:02 PM, David Holmes david.hol...@oracle.com wrote:
Hi Paul,
When we added j.u.c there was reluctance to add these methods to Thread -
this was the normal policy (for the time) of don't
On 10 feb 2015, at 15:23, Magnus Ihse Bursie magnus.ihse.bur...@oracle.com
wrote:
Here is an addition to the build system, that will compile native libraries
and executables and make them available for JTReg tests written in Java.
This patch is the result of the work (in serial,
The change without ORB.java looks okay to me.
Mandy
On 2/10/15 4:11 AM, Mark Sheppard wrote:
OK I'll remove it.
I thought that property files had been migrated from lib to conf, as
per conf/security, so I made the change
regards
Mark
On 10/02/2015 11:37, Alan Bateman wrote:
On 10/02/2015
10 feb 2015 kl. 16:10 skrev Staffan Larsen staffan.lar...@oracle.com:
On 10 feb 2015, at 15:23, Magnus Ihse Bursie magnus.ihse.bur...@oracle.com
wrote:
Here is an addition to the build system, that will compile native libraries
and executables and make them available for JTReg tests
Here is an addition to the build system, that will compile native
libraries and executables and make them available for JTReg tests
written in Java.
This patch is the result of the work (in serial, mostly) of Staffan
Larsen, David Simms and me. (And possible more that I don't know about.)
Hi,
One common use of Unsafe is boost the performance of comparing unsigned byte[]
by viewing as long[] (for example as performed by Guava or Cassandra). To
reduce the dependency on Unsafe we need a public and safe equivalent that works
on all platforms while meeting the performance
On 10/02/2015 10:46 PM, Paul Sandoz wrote:
Hi David,
On Feb 10, 2015, at 1:02 PM, David Holmes david.hol...@oracle.com wrote:
Hi Paul,
When we added j.u.c there was reluctance to add these methods to Thread - this
was the normal policy (for the time) of don't touch the core classes. So
This time really adding Doug Lea :)
On 11/02/2015 11:43 AM, David Holmes wrote:
Adding Doug Lea.
On 11/02/2015 12:51 AM, Paul Sandoz wrote:
On Feb 10, 2015, at 3:39 PM, Chris Hegarty chris.hega...@oracle.com
wrote:
Adding native methods to 166 classes will introduce another form of
Hi Magnus,
On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote:
Here is an addition to the build system, that will compile native
libraries and executables and make them available for JTReg tests
written in Java.
Sorry I'm missing the basics here: when does this compilation take
place? As part
Adding Doug Lea.
On 11/02/2015 12:51 AM, Paul Sandoz wrote:
On Feb 10, 2015, at 3:39 PM, Chris Hegarty chris.hega...@oracle.com wrote:
Adding native methods to 166 classes will introduce another form of dependency
on the platform that i would prefer to avoid.
Right. And I suspect that the
On 10 Feb 2015, at 11:35, Alan Bateman alan.bate...@oracle.com wrote:
On 09/02/2015 14:57, Chris Hegarty wrote:
:
Updated webrev [ spec and implementation] :
http://cr.openjdk.java.net/~chegar/8064924/04/
The updated javadoc looks good. I haven't had a chance yet to look at the
On 10/02/2015 07:21, A. Sundararajan wrote:
Please review http://cr.openjdk.java.net/~sundar/8068587/ for
https://bugs.openjdk.java.net/browse/JDK-8068587
This looks okay to me although it makes me wonder if JSR-223 will need
to be updated.
-Alan.
On 07/02/2015 00:22, Mark Sheppard wrote:
Hi Alan,
I had meant to remove the commented lines prior to generating the
patch
Okay, so ignoring that part then the rest looks good to me. Hopefully we
have enough tests in this area that run with a security manager to help
find any issues.
Looks OK to me. +1
/M
On 10 Feb 2015, at 08:21, A. Sundararajan
sundararajan.athijegannat...@oracle.com wrote:
Please review http://cr.openjdk.java.net/~sundar/8068587/ for
https://bugs.openjdk.java.net/browse/JDK-8068587
Thanks,
-Sundar
On Feb 10, 2015, at 12:25 AM, Roger Riggs roger.ri...@oracle.com wrote:
Hi,
After a protracted absence from working on JEP 102, the updated API draft
provides access to process hierarchies and individual process information;
as permitted by the OS. The relationship between Process and
Hi,
As part of the effort around Unsafe (some may have noticed some cleanup work) i
have been recently looking at the park/unpark methods.
The class java.util.concurrent.locks.LockSupport [1] has some thin public
wrappers around these methods:
public static void unpark(Thread thread) {
Happy to see this!
In ProcessHandle.Info would it be possible to include the environment variables
of the process as well?
How does ProcessHandle.allChildren() behave when process A launches B which
launches C, and B terminates? Is C included in allChildren() of A?
Thanks,
/Staffan
On 10
Hi Roger, Volker,
thanks for reviewing!
I added all requested changes:
@Roger
- use now Files.createTempDirectory to get a unique directory
- wrapped test in try/finally to cleanup afterwards
@Volker
- moved include up and added dependency to comment in io_util_md.h
- Now I use hostname.exe,
Oh I just realized/remembered why we use Unsafe for this - it is because
of the potential for intrinsics.
David
On 10/02/2015 10:02 PM, David Holmes wrote:
Hi Paul,
When we added j.u.c there was reluctance to add these methods to Thread
- this was the normal policy (for the time) of don't
On 10/02/2015 11:20, Mark Sheppard wrote:
thanks Alan
the updated corba part is at
http://cr.openjdk.java.net/~msheppar/8068682/corba/webrev.02/
I assume ORB.java isn't meant to be in this webrev (the lib-conf issue
is separate and I think will need an @implNote in additional to checking
thanks Alan
the updated corba part is at
http://cr.openjdk.java.net/~msheppar/8068682/corba/webrev.02/
regards
Mark
On 10/02/2015 09:14, Alan Bateman wrote:
On 07/02/2015 00:22, Mark Sheppard wrote:
Hi Alan,
I had meant to remove the commented lines prior to generating the
patch
Okay,
On 09/02/2015 14:57, Chris Hegarty wrote:
:
Updated webrev [ spec and implementation] :
http://cr.openjdk.java.net/~chegar/8064924/04/
The updated javadoc looks good. I haven't had a chance yet to look at
the implementation but I think you will need to update
top/make/common/CORE_PKGS.gmk
On 02/10/2015 12:25 AM, Roger Riggs wrote:
Hi,
After a protracted absence from working on JEP 102, the updated API draft
provides access to process hierarchies and individual process
information;
as permitted by the OS. The relationship between Process and
ProcessHandle
is clarified and the
Hi Paul,
When we added j.u.c there was reluctance to add these methods to Thread
- this was the normal policy (for the time) of don't touch the core
classes. So LockSupport is the public API and Unsafe was chosen as the
implementation as it is a de-facto interface to the VM from JDK code
OK I'll remove it.
I thought that property files had been migrated from lib to conf, as per
conf/security, so I made the change
regards
Mark
On 10/02/2015 11:37, Alan Bateman wrote:
On 10/02/2015 11:20, Mark Sheppard wrote:
thanks Alan
the updated corba part is at
(not enough time for real review)
I support Peter's approach. I know of no way to be reliably notified of
process termination on unix without a dedicated thread per subprocess (unix
is broken!). Given that, we want to keep its stack size small, which is
where the 32k comes from. Maybe on 64-bit
Hi Roger
This looks great already. My feedback is about process destruction:
Why isn't ProcessHandle::isDestroyForcible a static method?
For ProcessHandle::destroy and Process::destroy, I'd like to propose
replacing
Whether the process represented by this Process object is forcibly
On 02/10/2015 02:02 PM, Peter Levart wrote:
On 02/10/2015 12:35 PM, Peter Levart wrote:
ProcessHandle.completableFuture().cancel(true) forcibly destorys
(destroyForcibly()) the process *and* vice versa: destory[Forcibly]()
cancels the CompletableFuture. I don't know if this is the best way -
Hello,
Please review this typo fix for
JDK-8072843: Typo in the description of the
j.l.r.Executable.getAnnotatedReceiverType
Patch below; I spellchecked the rest of the comments and strings and
didn't find any other problems.
Thanks,
-Joe
diff -r 30f5fa716218
+1
On Feb 10, 2015, at 2:25 PM, joe darcy joe.da...@oracle.com wrote:
Hello,
Please review this typo fix for
JDK-8072843: Typo in the description of the
j.l.r.Executable.getAnnotatedReceiverType
Patch below; I spellchecked the rest of the comments and strings and didn't
find any
Hi Peter,
On 2/10/2015 6:35 AM, Peter Levart wrote:
On 02/10/2015 12:25 AM, Roger Riggs wrote:
Hi,
After a protracted absence from working on JEP 102, the updated API
draft
provides access to process hierarchies and individual process
information;
as permitted by the OS. The relationship
People will continue to want to access byte arrays (and direct byte
buffers) with C-like performance, and are currently using Unsafe to do so.
Hard to fix for real. Endianness and unaligned access are both
non-portable aspects. People don't want to pay for bounds checking and
especially not for
Hi Peter,
Yep, I hadn't gotten to improving that part of the implementation yet.
The threading needs to be revised; System threads and the limited stack
were used currently
to monitor processes (on Linux) but are not suitable for evaluating
CompletionStages.
Switching to some form of Executor
Hi Martin,
In this case i am trying to pick off one particularly common case, within the 9
time-frame, used in a number of popular libraries. In that context (including
that of the intrinsic referenced in the related issue) do you think this is
reasonable?
On Feb 10, 2015, at 8:48 PM, Martin
Hi Anthony,
On 2/10/2015 2:12 PM, Anthony Vanelverdinghe wrote:
Hi Roger
This looks great already. My feedback is about process destruction:
Why isn't ProcessHandle::isDestroyForcible a static method?
The Process API is subclassable and in that case the subclass
should be able to control
Hi Staffan,
On 2/10/2015 4:53 AM, Staffan Larsen wrote:
Happy to see this!
In ProcessHandle.Info would it be possible to include the environment variables
of the process as well?
The API was intended to provide a degree of control over subprocesses,
but not
be a diagnostic tool, there are
The addition of array comparison intrinsics makes sense - I've missed them
myself on occasion.
I was surprised that System.arraycopy hasn't been specialized for every
array type.
I guess the JIT is good at specializing all callers.
I don't know whether we will someday regret the explosion of
Hi Paul,
On 2/3/15 5:48 AM, Paul Sandoz wrote:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping/webrev/
This patch adds a new flat mapping collector to Collectors. This can be useful
if one needs to map 0 or more items into a downstream collector.
Mostly pretty
On Feb 10, 2015, at 3:39 PM, Chris Hegarty chris.hega...@oracle.com wrote:
Adding native methods to 166 classes will introduce another form of
dependency on the platform that i would prefer to avoid.
Right. And I suspect that the separate distributable of 166, outside of the
Java
On 02/10/2015 12:35 PM, Peter Levart wrote:
ProcessHandle.completableFuture().cancel(true) forcibly destorys
(destroyForcibly()) the process *and* vice versa: destory[Forcibly]()
cancels the CompletableFuture. I don't know if this is the best way -
can't decide yet. In particular, in the
On 02/09/2015 07:52 PM, Roger Riggs wrote:
On 2/9/15 6:44 PM, David M. Lloyd wrote:
Also, as a general comment, there isn't really a good explanation as
to what the difference is between a normal destroy and a forcible
destroy. Given that you've added an isDestroyForcible() method, I
think it
Hi David,
On Feb 10, 2015, at 1:02 PM, David Holmes david.hol...@oracle.com wrote:
Hi Paul,
When we added j.u.c there was reluctance to add these methods to Thread -
this was the normal policy (for the time) of don't touch the core classes. So
LockSupport is the public API and Unsafe was
On Feb 10, 2015, at 3:15 PM, Martin Buchholz marti...@google.com wrote:
I was surprised that System.arraycopy hasn't been specialized for every
array type.
I guess the JIT is good at specializing all callers.
Yes. Usually the arguments have specific static types the JIT can see.
The Object
Please review at your convenience.
Issue: https://bugs.openjdk.java.net/browse/JDK-8064562
Patch: http://cr.openjdk.java.net/~bpb/8064562/webrev.00/
Thanks,
Brian
Hi Paul,
I spent some time looking at this API. Overall it seems to me that things work a
bit more nicely when these methods are added to Pattern instead of Matcher.
Unfortunately there are some odd things with the existing API that make this
tradeoff not so obvious.
First, here's what a
45 matches
Mail list logo
