Hi Mandy,
On 22/02/2018 12:28 PM, mandy chung wrote:
On 2/21/18 6:08 PM, David Holmes wrote:
Hi Mandy,
tl;dr: I think this is now good to go.
On 22/02/2018 5:58 AM, mandy chung wrote:
Here is the updated webrev:
http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198249/webrev.04/
I added
On 2/21/18 6:08 PM, David Holmes wrote:
Hi Mandy,
tl;dr: I think this is now good to go.
On 22/02/2018 5:58 AM, mandy chung wrote:
Here is the updated webrev:
http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198249/webrev.04/
I added some comments to clarify the implementation.
Hi Mandy,
tl;dr: I think this is now good to go.
On 22/02/2018 5:58 AM, mandy chung wrote:
Here is the updated webrev:
http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198249/webrev.04/
I added some comments to clarify the implementation.
src/java.base/share/classes/java/lang/Shutdown.java
Here is the updated webrev:
http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198249/webrev.04/
I added some comments to clarify the implementation.
Mandy
On 2/21/18 11:34 AM, mandy chung wrote:
Hi David,
I think I'm clear on the implementation now (my mistake that I
neglected
Hi David,
I think I'm clear on the implementation now (my mistake that I neglected
ApplicationShutdownHooks). Shutdown class keeps the "system shutdown
hooks". ApplicationShutdownHooks is one system hook that starts all
application shutdown hooks and waits until they finish.
Hi Mandy,
On 21/02/2018 5:57 AM, mandy chung wrote:
Hi David,
I reworked the change in Shutdown class and uses jdk.internal.misc.VM to
maintain the shutdown state, either in progress or shutdown (i.e. all
shutdown hooks have been started).
What do you think this revised version:
Hi David,
I reworked the change in Shutdown class and uses jdk.internal.misc.VM to
maintain the shutdown state, either in progress or shutdown (i.e. all
shutdown hooks have been started).
What do you think this revised version:
On 2/16/18 11:11 AM, Martin Buchholz wrote:
The small optimization to avoid checking for "already finalized" could
be done in a follow-up.
Before working on Finalizer.java I was not really aware of the global
"unfinalized" data structure with a non-scalable lock. This could
probably be
On Fri, Feb 16, 2018 at 10:26 AM, mandy chung
wrote:
>
>
> On 2/16/18 6:52 AM, Peter Levart wrote:
>
> I think that the following now never applies (in Finalizer) since
> ReferenceQueue never returns the same Reference object more than once:
>
> 71 if
On 2/16/18 6:52 AM, Peter Levart wrote:
I think that the following now never applies (in Finalizer) since
ReferenceQueue never returns the same Reference object more than once:
71 if (this.next == this) // already finalized
72 return;
You could change it
On 2/16/18 4:54 AM, David Holmes wrote:
On 16/02/2018 10:12 PM, Alan Bateman wrote:
On 16/02/2018 04:09, mandy chung wrote:
Merged. New version:
http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198249/webrev.02/
Good to see this change.
One comment on Runtime.exec is that the 3rd
Hi Mandy,
On 02/16/2018 05:09 AM, mandy chung wrote:
On 2/15/18 7:29 PM, Martin Buchholz wrote:
This also changes the handling of (undeprecated) method
runFinalization and that's obviously related but could be a separate
changeset.
I agree I should separate the runFinalization change.
On 16/02/2018 10:12 PM, Alan Bateman wrote:
On 16/02/2018 04:09, mandy chung wrote:
Merged. New version:
http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198249/webrev.02/
Good to see this change.
One comment on Runtime.exec is that the 3rd paragraph of the updated
spec is difficult to
On 16/02/2018 04:09, mandy chung wrote:
Merged. New version:
http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198249/webrev.02/
Good to see this change.
One comment on Runtime.exec is that the 3rd paragraph of the updated
spec is difficult to read (too many "ifs" and "thens"). What would
Hi Mandy,
On 16/02/2018 1:20 PM, mandy chung wrote:
On 2/15/18 6:11 PM, David Holmes wrote:
Hi Mandy,
Good to see this go. A few minor comments.
First I've added comments on the CSR as some of the doc changes don't
read correctly.
Thanks for catching it. What do you think about this
On 2/15/18 7:29 PM, Martin Buchholz wrote:
This also changes the handling of (undeprecated) method
runFinalization and that's obviously related but could be a separate
changeset.
I agree I should separate the runFinalization change. I leave it in
this webrev for now. I will send out
This also changes the handling of (undeprecated) method runFinalization and
that's obviously related but could be a separate changeset.
We'll need to merge with my own pending change to Finalizer.java.
On 2/15/18 6:11 PM, David Holmes wrote:
Hi Mandy,
Good to see this go. A few minor comments.
First I've added comments on the CSR as some of the doc changes don't
read correctly.
Thanks for catching it. What do you think about this revision:
* All registered {@link
On 2/15/18 3:06 PM, mandy chung wrote:
Runtime.runFinalizersOnExit has been deprecated since 1.2 (1998)
and deprecated for removal in JDK 9. We analyzed the maven central
artifacts few years ago that show very few uses of it. I also
survey a recent version of most of the maven artifacts that
Hi Mandy,
Good to see this go. A few minor comments.
First I've added comments on the CSR as some of the doc changes don't
read correctly.
src/hotspot/share/runtime/thread.cpp
This comment doesn't read correctly:
! // won't be run. Note that if a shutdown hook was registered
//
On 2/15/18 4:18 PM, Stuart Marks wrote:
On 2/15/18 3:06 PM, mandy chung wrote:
Runtime.runFinalizersOnExit has been deprecated since 1.2 (1998)
and deprecated for removal in JDK 9. We analyzed the maven central
artifacts few years ago that show very few uses of it. I also
survey a recent
21 matches
Mail list logo