Webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/
This fixes the finalization implementation to invoke the finalize method
via shared secret so that it will call the same method as the bytecode
invocation.
The current implementation uses JNI_GetMethodID to find the
2013/11/1 4:15 -0700, mandy.ch...@oracle.com:
> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/
Looks good.
Just one question: In Finalizer.java, at line 97 you look up the
JavaLangAccess object every single time. Is it worth caching that
earlier, maybe when the finalize threa
On 11/1/13 1:37 PM, mark.reinh...@oracle.com wrote:
2013/11/1 4:15 -0700, mandy.ch...@oracle.com:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/
Looks good.
Just one question: In Finalizer.java, at line 97 you look up the
JavaLangAccess object every single time. Is it wort
a.net
> Subject: JDK-8027351: (ref) Base's class finalize method not invoked if
> a private finalize method exists in its subclass
>
> Webrev at:
> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/
>
> This fixes the finalization implementation to invoke t
Of Mandy Chung
> Sent: Friday, November 1, 2013 22:11
> To: mark.reinh...@oracle.com
> Cc: core-libs-dev@openjdk.java.net
> Subject: Re: JDK-8027351: (ref) Base's class finalize method not invoked
> if a private finalize method exists in its subclass
>
> On 11/1/13
On 01/11/2013 21:11, Mandy Chung wrote:
I was expecting that would get optimized during runtime and it's a
simple getter method. It's a good suggestion to cache it at the
finalize thread start time and here is the revised webrev:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev
On 11/01/2013 10:11 PM, Mandy Chung wrote:
On 11/1/13 1:37 PM, mark.reinh...@oracle.com wrote:
2013/11/1 4:15 -0700, mandy.ch...@oracle.com:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/
Looks good.
Just one question: In Finalizer.java, at line 97 you look up the
JavaLan
Hi Mandy,
On 2/11/2013 7:11 AM, Mandy Chung wrote:
On 11/1/13 1:37 PM, mark.reinh...@oracle.com wrote:
2013/11/1 4:15 -0700, mandy.ch...@oracle.com:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/
Looks good.
Just one question: In Finalizer.java, at line 97 you look up the
On 11/2/2013 3:41 AM, Peter Levart wrote:
On 11/01/2013 10:11 PM, Mandy Chung wrote:
On 11/1/13 1:37 PM, mark.reinh...@oracle.com wrote:
2013/11/1 4:15 -0700, mandy.ch...@oracle.com:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/
Looks good.
Just one question: In Finali
On 11/3/2013 5:32 PM, David Holmes wrote:
Hi Mandy,
On 2/11/2013 7:11 AM, Mandy Chung wrote:
On 11/1/13 1:37 PM, mark.reinh...@oracle.com wrote:
2013/11/1 4:15 -0700, mandy.ch...@oracle.com:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/
Looks good.
Just one question: I
Hi Mandy,
I'll wait for the updated webrev.
FYI I wasn't suggesting any VM changes regarding GetMethodID. I assumed,
incorrectly, that once you had the method ID you could query to see if
it was private. That said if you called GetMethodID on Object.class and
then did the CallVoidMethod(env,
On 11/04/2013 05:45 AM, Mandy Chung wrote:
On 11/3/2013 5:32 PM, David Holmes wrote:
Hi Mandy,
On 2/11/2013 7:11 AM, Mandy Chung wrote:
On 11/1/13 1:37 PM, mark.reinh...@oracle.com wrote:
2013/11/1 4:15 -0700, mandy.ch...@oracle.com:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/w
On 11/04/2013 07:52 AM, Peter Levart wrote:
Also VM.awaitBooted seems inherently risky as a general method as
you would have to make sure that it is never called by the main VM
initialization thread. Perhaps handle this in
sun.misc.SharedSecrets.getJavaLangAccess so it is less 'general'?
Tha
On 11/04/2013 05:45 AM, Mandy Chung wrote:
That said I think Peter may be right that there could be races with
agents triggerring explicit finalization requests early in the VM
initialization process - which means any blocking operation dependent
on other parts of the initialization sequence co
On 04/11/2013 08:33, Peter Levart wrote:
:
What about the following helper class in java.lang package:
If public then it leaks into the Java SE API. I think using
SharedSecrets should be okay, assuming we can sort out any potential
races getting to JavaLangAccess.
-Alan.
On 11/04/2013 09:48 AM, Alan Bateman wrote:
On 04/11/2013 08:33, Peter Levart wrote:
:
What about the following helper class in java.lang package:
If public then it leaks into the Java SE API. I think using
SharedSecrets should be okay, assuming we can sort out any potential
races getting to
On Nov 2, 2013, at 10:03 AM, Alan Bateman wrote:
> On 01/11/2013 21:11, Mandy Chung wrote:
>>
>> I was expecting that would get optimized during runtime and it's a simple
>> getter method. It's a good suggestion to cache it at the finalize thread
>> start time and here is the revised webrev:
On 11/3/13 10:52 PM, Peter Levart wrote:
On 11/04/2013 05:45 AM, Mandy Chung wrote:
On 11/3/2013 5:32 PM, David Holmes wrote:
Hi Mandy,
On 2/11/2013 7:11 AM, Mandy Chung wrote:
On 11/1/13 1:37 PM, mark.reinh...@oracle.com wrote:
2013/11/1 4:15 -0700, mandy.ch...@oracle.com:
http://cr.openj
Thank you all for the suggestions.
Before the VM initialization is completed, any agent ought to be careful
in what things it can do and what shouldn't do. I think it's reasonable
to ignore System.runFinalization if it's called at early startup phase.
I'm unclear if there is any use case tha
Hi Mandy,
This all seems quite reasonable to me.
Two minor nits:
1. The "delay ntil" typo in Finalizer.java is still present.
2. In VM.java. booted need not be volatile now that it is only accessed
within a locked region. Also awaitBooted might as well be void as it can
only ever return true
On 11/4/2013 6:03 PM, David Holmes wrote:
Hi Mandy,
This all seems quite reasonable to me.
Two minor nits:
1. The "delay ntil" typo in Finalizer.java is still present.
Missed that :(
2. In VM.java. booted need not be volatile now that it is only
accessed within a locked region. Also await
On 5/11/2013 12:21 PM, Mandy Chung wrote:
On 11/4/2013 6:03 PM, David Holmes wrote:
Hi Mandy,
This all seems quite reasonable to me.
Two minor nits:
1. The "delay ntil" typo in Finalizer.java is still present.
Missed that :(
2. In VM.java. booted need not be volatile now that it is only
On 11/4/2013 6:29 PM, David Holmes wrote:
2. In VM.java. booted need not be volatile now that it is only
accessed within a locked region.
Oops my bad! The accessor wasn't synchronized but now is. Your call
whether to leave as is or revert to previous.
I'm fine with making isBooted() to a syn
On 11/05/2013 03:21 AM, Mandy Chung wrote:
On 11/4/2013 6:03 PM, David Holmes wrote:
Hi Mandy,
This all seems quite reasonable to me.
Two minor nits:
1. The "delay ntil" typo in Finalizer.java is still present.
Missed that :(
2. In VM.java. booted need not be volatile now that it is only
On Nov 5, 2013, at 3:21 AM, Mandy Chung wrote:
>> 2. In VM.java. booted need not be volatile now that it is only accessed
>> within a locked region. Also awaitBooted might as well be void as it can
>> only ever return true.
>>
>
> Fixed. Revised webrev at:
> http://cr.openjdk.java.net/~mchung
On 05/11/2013 02:21, Mandy Chung wrote:
Fixed. Revised webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.03/
I looked at the latest webrev.
Having runFinalization and runAllFinalizers be a no-open during
initialization is reasonable (it should never happen).
I agre
On Nov 5, 2013, at 8:26 AM, Peter Levart wrote:
>
> P.S. I'm curious about the strange seemingly unneeded code fragments in
> FinalizerThread and both Runnables. For example:
>
> 169 forkSecondaryFinalizer(new Runnable() {
> 170*private volatile boolean running;*
> 171 publi
On 05/11/2013 10:59, Paul Sandoz wrote:
On Nov 5, 2013, at 8:26 AM, Peter Levart wrote:
P.S. I'm curious about the strange seemingly unneeded code fragments in
FinalizerThread and both Runnables. For example:
169 forkSecondaryFinalizer(new Runnable() {
170*private volatile boolean ru
On 11/05/2013 12:33 PM, Chris Hegarty wrote:
On 05/11/2013 10:59, Paul Sandoz wrote:
On Nov 5, 2013, at 8:26 AM, Peter Levart wrote:
P.S. I'm curious about the strange seemingly unneeded code fragments
in FinalizerThread and both Runnables. For example:
169 forkSecondaryFinalizer(n
On 11/5/2013 1:11 AM, Paul Sandoz wrote:
On Nov 5, 2013, at 3:21 AM, Mandy Chung wrote:
2. In VM.java. booted need not be volatile now that it is only accessed within
a locked region. Also awaitBooted might as well be void as it can only ever
return true.
Fixed. Revised webrev at:
http://
On 11/5/2013 2:38 AM, Alan Bateman wrote:
On 05/11/2013 02:21, Mandy Chung wrote:
Fixed. Revised webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.03/
I looked at the latest webrev.
Having runFinalization and runAllFinalizers be a no-open during
initialization is re
Ship it! :)
And again apologies for sending you down the wrong path on the volatile.
David
On 6/11/2013 6:25 AM, Mandy Chung wrote:
On 11/5/2013 2:38 AM, Alan Bateman wrote:
On 05/11/2013 02:21, Mandy Chung wrote:
Fixed. Revised webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/80
On 11/5/2013 4:23 PM, David Holmes wrote:
Ship it! :)
Thanks for the review.
And again apologies for sending you down the wrong path on the volatile.
No apology needed. I missed its usage in sun.misc.VM.
Mandy
David
On 6/11/2013 6:25 AM, Mandy Chung wrote:
On 11/5/2013 2:38 AM, Ala
33 matches
Mail list logo
