> On Jun 27, 2015, at 2:31 AM, Peter Levart wrote:
>
>>> Are any of the features of this prototype interesting for you and worth
>>> pursuing further?
>> This mostly appears to be a question for core-libs; that's where the
>> proposed changes are located. GC is involved mostly to ensure the
>>
Hi Kim,
Thanks again for looking into changed code. Some comments to your
comments for easier understanding of my code (when you have time)...
On 06/26/2015 11:36 PM, Kim Barrett wrote:
On Jun 22, 2015, at 3:33 AM, Peter Levart wrote:
Hi Kim,
Sorry, I just noticed you'd sent an update a fe
On Jun 22, 2015, at 3:33 AM, Peter Levart wrote:
>
> Hi Kim,
Sorry, I just noticed you'd sent an update a few days ago.
I don't have time to look carefully today, but a few quick comments.
>
> On 06/09/2015 07:44 AM, Peter Levart wrote:
>> On 06/09/2015 04:03 AM, Kim Barrett wrote:
>>> On May
Hi Kim,
On 06/09/2015 07:44 AM, Peter Levart wrote:
Hi Kim,
Thanks for taking a look at this code.
On 06/09/2015 04:03 AM, Kim Barrett wrote:
On May 31, 2015, at 3:32 PM, Peter Levart wrote:
So, for the curious, here's the improved prototype:
http://cr.openjdk.java.net/~plevart/misc/
On 06/09/2015 01:41 AM, Kim Barrett wrote:
On Jun 8, 2015, at 1:45 PM, Rezaei, Mohammad A. wrote:
If that's the case, the documentation needs to be more clear :-) It currently
says:
"Clears this reference object. Invoking this method will not cause this object to
be enqueued."
I interpre
Hi Kim,
Thanks for taking a look at this code.
On 06/09/2015 04:03 AM, Kim Barrett wrote:
On May 31, 2015, at 3:32 PM, Peter Levart wrote:
So, for the curious, here's the improved prototype:
http://cr.openjdk.java.net/~plevart/misc/JEP132/ReferenceHandling/webrev.02/
And here are the
On May 31, 2015, at 3:32 PM, Peter Levart wrote:
>
> So, for the curious, here's the improved prototype:
>
>
> http://cr.openjdk.java.net/~plevart/misc/JEP132/ReferenceHandling/webrev.02/
>
> And here are the improved benchmarks (with some results inline):
>
> http://cr.openjdk.java.n
On Jun 8, 2015, at 1:45 PM, Rezaei, Mohammad A. wrote:
>
> If that's the case, the documentation needs to be more clear :-) It currently
> says:
>
> "Clears this reference object. Invoking this method will not cause this
> object to be enqueued."
>
> I interpret that as meaning the reference
On Jun 8, 2015, at 4:20 PM, Peter Levart wrote:
>
>
>
> On 06/08/2015 09:47 PM, Kim Barrett wrote:
>> On Jun 6, 2015, at 11:02 AM, Peter Levart
>> wrote:
>>
>>> I understand that it would be desirable for a finalizable object to be made
>>> "untracked" as soon as it is manually cleaned-up.
On 06/08/2015 09:47 PM, Kim Barrett wrote:
On Jun 6, 2015, at 11:02 AM, Peter Levart wrote:
I understand that it would be desirable for a finalizable object to be made
"untracked" as soon as it is manually cleaned-up. This would most certainly
give a relief to GC as it could reclaim such un
On Jun 6, 2015, at 11:02 AM, Peter Levart wrote:
>
> I understand that it would be desirable for a finalizable object to be made
> "untracked" as soon as it is manually cleaned-up. This would most certainly
> give a relief to GC as it could reclaim such untracked objects immediately
> like nor
d
confusion?
Thanks
Moh
>-Original Message-
>From: Peter Levart [mailto:peter.lev...@gmail.com]
>Sent: Monday, June 08, 2015 1:07 PM
>To: Rezaei, Mohammad A. [Tech]
>Cc: 'hotspot-gc-...@openjdk.java.net openjdk.java.net'; 'core-libs-
>d...@openjdk.java.net'
>S
On 06/08/2015 06:53 PM, Rezaei, Mohammad A. wrote:
Shouldn't we extend the same notion to other reference types? For Weak/Soft
references, the (rough) equivalent would be a method of the kind:
public void markUnqueueable() // suggestions for better method name most
welcome!
{
this.q
06, 2015 11:03 AM
>To: Jonathan Payne
>Cc: 'hotspot-gc-...@openjdk.java.net openjdk.java.net'; 'core-libs-
>d...@openjdk.java.net'
>Subject: Re: JEP 132: More-prompt finalization (Re: Another take on
>Finalization)
>
>Hi Jonathan,
>
>On 06/05/2015 11:11 PM, J
the discussion currently ongoing in the thread entitled
"JEP 132: More-prompt finalization”.
My problem was that finalization was not being run at all with the G1
collector. Not at all. That would have been fine with me because none of the
existing objects in the Finalizer queue actually n
Hello,
Am Fri, 29 May 2015 12:18:06 +1000
schrieb David Holmes :
> I guess I'm very concerned about the premise that finalization should
> scale to millions of objects and be performed highly concurrently.
I would agree that it is a bad idea to design applications for such
demanding workloads a
Hi Peter,
Interesting email. I think it is a thoughtful contribution and these are great
responses to concerns and questions. I hope it receives the due consideration
it deserves.
Kind regards,
Kirk
On May 31, 2015, at 9:32 PM, Peter Levart wrote:
> Hi,
>
> Thanks for views and opinions. I'
>> -Original Message-
>> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf
>> Of Kirk Pepperdine
>> Sent: Thursday, May 28, 2015 11:58 PM
>> To: david.hol...@oracle.com Holmes
>> Cc: hotspot-gc-...@openjdk.java.net openjdk.java.ne
ith meaningful numbers.
Thanks
Moh
From: Peter Levart [mailto:peter.lev...@gmail.com]
Sent: Monday, June 01, 2015 5:04 AM
To: Rezaei, Mohammad A. [Tech]
Cc: 'hotspot-gc-...@openjdk.java.net openjdk.java.net';
'core-libs-dev@openjdk.java.net'
Subject: Re: JEP 132: More-prom
Hi Moh,
On 06/01/2015 04:42 AM, Rezaei, Mohammad A. wrote:
The problems start with the ReferenceQueue object and the heavy
synchronization in it. Consider structures like j.u.WeakHashMap that
need to expunge entries. If such structures are made somewhat
concurrent, the lock in ReferenceQueue
The problems start with the ReferenceQueue object and the heavy synchronization
in it. Consider structures like j.u.WeakHashMap that need to expunge entries.
If such structures are made somewhat concurrent, the lock in ReferenceQueue
starts to become a serious problem:
- In structures
Hi,
Thanks for views and opinions. I'll try to confront them in-line...
On 05/29/2015 04:18 AM, David Holmes wrote:
Hi Peter,
I guess I'm very concerned about the premise that finalization should
scale to millions of objects and be performed highly concurrently. To
me that's sending the wron
-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf
>Of Kirk Pepperdine
>Sent: Thursday, May 28, 2015 11:58 PM
>To: david.hol...@oracle.com Holmes
>Cc: hotspot-gc-...@openjdk.java.net openjdk.java.net; core-libs-
>d...@openjdk.java.net
>Subject: Re: JEP 132: More-prom
Hi Peter,
It is a very interesting proposal but to further David’s comments, the
life-cycle costs of reference objects is horrendous of which the actual process
of finalizing an object is only a fraction of that total cost. Unfortunately
your micro-benchmark only focuses on one aspect of that c
Hi Peter,
I guess I'm very concerned about the premise that finalization should
scale to millions of objects and be performed highly concurrently. To me
that's sending the wrong message about finalization. It also isn't the
most effective use of cpu resources - most people would want to do
us
Hi,
Did you know that the following simple loop:
public class FinalizableBottleneck {
static boolean no;
@Override
protected void finalize() throws Throwable {
// empty finalize() method does not make the object finalizable
// (it is not even registered on the finali
Hi,
Is there any interest to propose JEP 132 for JDK9 ?
I have some ideas how to achieve it's goals.
Regards, Peter
27 matches
Mail list logo
