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
wrote:
Adding native methods to 166 classes will introduce another form of
dependency on the platform that i
On 10/02/2015 10:46 PM, Paul Sandoz wrote:
Hi David,
On Feb 10, 2015, at 1: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 touch the core classes. So
LockSupport is the public A
Adding Doug Lea.
On 11/02/2015 12:51 AM, Paul Sandoz wrote:
On Feb 10, 2015, at 3:39 PM, Chris Hegarty 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
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 o
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 sim
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
On Feb 10, 2015, at 3:15 PM, Martin Buchholz 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 formal type does
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 arra
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 good
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 be
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 that
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
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 a
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 bet
+1
On Feb 10, 2015, at 2:25 PM, joe darcy 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 other probl
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
src/java.base/share/cl
(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
terminate
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 -
c
On 10 Feb 2015, at 11:35, Alan Bateman 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
> implementation bu
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 :
>
>
>> On 10 feb 2015, at 15:23, 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.
>>
>> This patch is the
> On 10 feb 2015, at 15:23, 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.
>
> This patch is the result of the work (in serial, mostly) of Staffan Larsen,
>
On Feb 10, 2015, at 3:39 PM, Chris Hegarty 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 Platform, would not wan
On 10 Feb 2015, at 12:46, Paul Sandoz wrote:
> Hi David,
>
> On Feb 10, 2015, at 1: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 touch the core classes.
>> So Loc
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 expectation
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.)
In
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 m
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 implem
Hi David,
On Feb 10, 2015, at 1: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 touch the core classes. So
> LockSupport is the public API and Unsafe was chosen as the impl
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
http://cr.openjdk.java.
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 tou
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
rath
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
fo
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
/make/common/CORE_PKGS.gmk for
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 s
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,
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) {
On Feb 10, 2015, at 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 cla
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, whi
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 fe
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.
-A
Looks OK to me. +1
/M
> On 10 Feb 2015, at 08:21, A. Sundararajan
> wrote:
>
> Please review http://cr.openjdk.java.net/~sundar/8068587/ for
> https://bugs.openjdk.java.net/browse/JDK-8068587
>
> Thanks,
> -Sundar
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.
45 matches
Mail list logo
