On 10/10/2014 8:10 AM, Claes Redestad wrote:
Hi all,
please review this patch which attempts to clean up synchronization
and improve scalability when
defining and getting java.lang.Package objects.
I agree with David that getting Package objects are not performance
critical. On the other ha
On 10/10/2014 10:42 PM, Vladimir Ivanov wrote:
Remi,
Why do you need getHistoricInt ?
Is it because Unsafe.getInt() doesn't do any constant folding ?
Exactly. I need a compile-time constant to feed it to the compiler to
guide compilation.
BTW, why getHistoricInt is named getHistoricInt ?
F
Remi,
Why do you need getHistoricInt ?
Is it because Unsafe.getInt() doesn't do any constant folding ?
Exactly. I need a compile-time constant to feed it to the compiler to
guide compilation.
BTW, why getHistoricInt is named getHistoricInt ?
From application perspective, the call returns cur
Hi Vladimir,
Why do you need getHistoricInt ?
Is it because Unsafe.getInt() doesn't do any constant folding ?
BTW, why getHistoricInt is named getHistoricInt ?
cheers,
Rémi
On 10/10/2014 09:08 PM, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~vlivanov/8059877/webrev.00/
https://bugs.open
http://cr.openjdk.java.net/~vlivanov/8059877/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8059877
LambdaForm sharing introduces profile pollution in compiled LambdaForms.
The most serious consequence is inlining distortion, which severely
degrade peak performance. The main victim is guar
Daniel,
Looks good. As always, thanks for fixing this.
Jason
> Date: Fri, 10 Oct 2014 17:39:55 +0200
> From: daniel.fu...@oracle.com
> To: stani...@riflexo.com; core-libs-dev@openjdk.java.net
> CC: jason_mehr...@hotmail.com
> Subject: Re: RFR: 8060132: H
Thanks and approved!
Seems suitable for a backport to 8u if you want to do that.
Personally I would not add the openjdk test, but use noreg-jck, but up to
you. Your test is certainly more focused on the bug fix than our jsr166
tck test.
On Fri, Oct 10, 2014 at 8:29 AM, Chris Hegarty
wrote:
>
Thanks for reviewing! Pushed.
-Konstantin
10.10.2014 19:06, Vladimir Ivanov пишет:
Looks good.
Best regards,
Vladimir Ivanov
On 10/9/14, 12:44 PM, Konstantin Shefov wrote:
Hi,
I have updated the webrev to take into account the JDK 9 new feature
with segmented code cache.
http://cr.openjdk.j
Hi David!
On 10/10/2014 05:22 PM, David Holmes wrote:
Hi Claes,
On 11/10/2014 1:10 AM, Claes Redestad wrote:
Hi all,
please review this patch which attempts to clean up synchronization and
improve scalability when defining and getting java.lang.Package objects.
Is this a real problem or a t
On 10/10/14 17:10, Stanimir Simeonoff wrote:
persistentLoggers should be cleared on reset(), imo.
Yes - I was wondering about that too, it's a bit tricky to
get it right (WRT MT-safety) :-(.
Also using "count" and then "for in" to loop over an array looks a bit
ugly, should be just "for (int
This is a formal review request for pulling the latest FutureTask from
the 166 CVS.
Webrev:
http://cr.openjdk.java.net/~chegar/8060052/webrev.00/webrev/
The most significant issue being addresses is that
task.get(Long.MIN_VALUE, NANOSECONDS) does not timeout for a really
really long time,
Hi Claes,
On 11/10/2014 1:10 AM, Claes Redestad wrote:
Hi all,
please review this patch which attempts to clean up synchronization and
improve scalability when defining and getting java.lang.Package objects.
Is this a real problem or a theoretical one? I've not previously heard
of getting Pa
This was already approved Konstantin :
http://mail.openjdk.java.net/pipermail/jdk8u-dev/2014-October/002118.html
If it's a clean import (patch wise) then - there's no need for a
separate review. If
there was changes to the 8u patch (apart from modular path name changes)
then
please get a revie
Please disregard the remark about "count", as any exception would make the
use of the index variable incorrect.
Stanimir
On Fri, Oct 10, 2014 at 6:10 PM, Stanimir Simeonoff
wrote:
> persistentLoggers should be cleared on reset(), imo.
>
> Also using "count" and then "for in" to loop over an arr
persistentLoggers should be cleared on reset(), imo.
Also using "count" and then "for in" to loop over an array looks a bit
ugly, should be just "for (int i=0; i
wrote:
> Hi,
>
> Please find below a possible fix for:
>
> 8060132: Handlers configured on abstract nodes in logging.properties are
> n
Hi all,
please review this patch which attempts to clean up synchronization and
improve scalability when
defining and getting java.lang.Package objects.
webrev: http://cr.openjdk.java.net/~redestad/8060130/webrev.02/
bug: https://bugs.openjdk.java.net/browse/JDK-8060130
Testing: jtreg, UTE vm
Looks good.
Best regards,
Vladimir Ivanov
On 10/9/14, 12:44 PM, Konstantin Shefov wrote:
Hi,
I have updated the webrev to take into account the JDK 9 new feature
with segmented code cache.
http://cr.openjdk.java.net/~kshefov/8058733/webrev.02
Please, review.
-Konstantin
On 08.10.2014 21:25,
Hi,
Please find below a possible fix for:
8060132: Handlers configured on abstract nodes in logging.properties are
not always properly closed
https://bugs.openjdk.java.net/browse/JDK-8060132
webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8060132/webrev.00/
Other options have been discusse
On 10/10/14 16:36, Stanimir Simeonoff wrote:
The Handler automatic closure remains problematic as they don't have a
defined lifecycle. close() should be invoked after there are no
references and it requires calling a potentially overridden method. It
can be carried by PhantomReference+WeakRefence
On Fri, Oct 10, 2014 at 5:13 PM, Jason Mehrens
wrote:
> Hi Daniel, Stanimir,
>
>
> Closing the Handler is the main goal which takes care of the lock files.
> As far as a strong reference to the logger you don't need that. What you
> need to do is store a reference to the Logger.handlers List in
On 10/10/14 16:13, Jason Mehrens wrote:
Hi Daniel, Stanimir,
Closing the Handler is the main goal which takes care of the lock files. As
far as a strong reference to the logger you don't need that. What you need to
do is store a reference to the Logger.handlers List in the
LogManager$Logge
Hi,
I have logged https://bugs.openjdk.java.net/browse/JDK-8060132.
I will start a new thread for discussing this issue.
best regards,
-- daniel
On 10/10/14 10:02, Stanimir Simeonoff wrote:
Hi,
LogManager.reset() should invoke a package private method to delete all
lock files. However, that
Hi Daniel, Stanimir,
Closing the Handler is the main goal which takes care of the lock files. As
far as a strong reference to the logger you don't need that. What you need to
do is store a reference to the Logger.handlers List in the
LogManager$LoggerWeakRef and reap the handlers inside of
Hi Stanimir, Jason,
On 10/10/14 10:02, Stanimir Simeonoff wrote:
Hi,
LogManager.reset() should invoke a package private method to delete all
lock files. However, that would require holding the FileHandler.locks
monitor during the resetting of FileHandlers, not just the deletion
process. Somethi
Thanks Joe,
Will modify and check the tests accordingly.
Brian, I guess you are still ok with these code changes ?
Thanks a lot both of you for the reviewing.
Thanks a lot William for checking with your own tests. That is very much
appreciated ! ;-)
Olivier.
On 09/10/2014 19:16, Joe Darc
Hello,
Please review and approve the backport of the test bug fix to 8u40
The bug: https://bugs.openjdk.java.net/browse/JDK-8058695
The webrev: http://cr.openjdk.java.net/~kshefov/8058695/8u-dev/webrev.00
Thanks
-Konstantin
Gently reminder
On 09.10.2014 19:56, Joe Darcy wrote:
Looks fine Konstantin.
(These tests have been failing very often since they were pushed. If
your fix isn't pushed today, I'd argue for the tests being excluded.)
Please, review
Thanks,
-Joe
On 10/9/2014 1:44 AM, Konstantin Shefov wrot
Hi,
LogManager.reset() should invoke a package private method to delete all
lock files. However, that would require holding the FileHandler.locks
monitor during the resetting of FileHandlers, not just the deletion
process. Something like that, plus new PrivilegedAction().
static void deleteAllLock
28 matches
Mail list logo
