Hi Mandy,
Thanks for the review. Webrevs updated as suggested:
http://cr.openjdk.java.net/~naoto/8189272/webrev.01/
http://cr.openjdk.java.net/~naoto/8189291/webrev.01/
Naoto
On 10/20/17 2:45 PM, mandy chung wrote:
On 10/20/17 2:20 PM, Naoto Sato wrote:
Hello,
Please review the changes fo
On 10/20/17 2:20 PM, Naoto Sato wrote:
Hello,
Please review the changes for the following two issues:
8189272: CLDR and JRE LocaleProviderAdapters silently swallow
exceptions [1]
8189291: Test policy should extend the default system policy [2]
The proposed fixes for the above issues are lo
Hello,
Please review the changes for the following two issues:
8189272: CLDR and JRE LocaleProviderAdapters silently swallow exceptions [1]
8189291: Test policy should extend the default system policy [2]
The proposed fixes for the above issues are located below, respectively:
http://cr.openjd
I created https://bugs.openjdk.java.net/browse/JDK-8189752 to track this.
Mandy
On 10/20/17 10:35 AM, Rafael Winterhalter wrote:
Hei Mandy,
thank you for your quick reply.
The benchmark is already only capturing the stack frame object. I ran
the benchmark with the transformation as a comparis
This would could also make sense for asynchronous logging with Log4j 2. We
currently disabled capturing location information for asynchronous logging as
capturing the information before passing the information to the thread doing
the logging is fairly expensive. Being able to capture the stack t
Hei Mandy,
thank you for your quick reply.
The benchmark is already only capturing the stack frame object. I ran the
benchmark with the transformation as a comparison and it is indeed slower
due to extra work. The JIT code suggests the native method plus monitor to
be the major cost here but it is
Hi Rafael,
Thanks for the feedback. We did some investigation in understanding the
overhead of Throwable if it used StackWalker API [1]. It did come to
mind whether the StackWalker API should provide a way to walk the
backtrace which we should do the investigation with JDK-8141239.
The ben
I posted it few days ago (and got the id 9051213). I think it's still being
reviewed.
2017-10-11 17:11 GMT-07:00 Naoto Sato :
> Yes. Please go ahead and file a bug report. Thanks.
>
> Naoto
>
> On 10/11/17 5:04 PM, Clément Guillaume wrote:
>
>> Hi,
>>
>> I verified that using java.locale.provider
Hi Claes,
This looks good. And can even be backported if desired. If/When
Christoph's proposal to add Executable.getParameterType(index) gets
accepted, all getParameterTypes() usages will be fixed at once,
including this one...
Regards, Peter
On 10/20/2017 04:10 PM, Claes Redestad wrote:
H
Hi,
please review this patch, contributed by Christoph Dreis, to speed up
AnnotationInvocationHandler.invoke, primarily by avoiding cloning the
Method parameterTypes array unnecessarily.
Webrev: http://cr.openjdk.java.net/~redestad/8189266/jdk.00/
Bug: https://bugs.openjdk.java.net/browse/JD
Hi Remi,
thank you for your quick reply! I just changed the benchmark to use:
stackFrameStream.skip(startFrame).limit(stackDepth).collect(Collectors.toList());
and it yields a small improvement.
Best regards, Rafael
2017-10-20 15:54 GMT+02:00 Remi Forax :
> Hi Rafael,
> stream.iterator() is usu
Hi Rafael,
stream.iterator() is usually super slow*, did you try with toArray() or
forEach() instead ?
Rémi
* you want to see a push based API (Stream) as a pull based API (Iterator)
- Mail original -
> De: "Rafael Winterhalter"
> À: "core-libs-dev"
> Envoyé: Vendredi 20 Octobre 2017 1
Hello,
a typical patern when reading the stack of the current thread in tooling
like performance monitoring used to imply the creation of an instance of
Throwable and to process this instance's attached stack in another thread.
The performance cost is shared about 10/90 for creating a new throwabl
Hi Christoph,
On 2017-10-20 13:45, Christoph Dreis wrote:
Hey,
while discussing JDK-8029019 & JDK-8189266 Claes came up with the idea to
introduce non-copying access to the underlying parameter types of an
Executable [1].
I only recalled Peter had a version of his patch for 8029019 that
incl
Hey,
while discussing JDK-8029019 & JDK-8189266 Claes came up with the idea to
introduce non-copying access to the underlying parameter types of an
Executable [1]. While there is a (for a good reason?) package-private
Method.getSharedParameterTypes() already I thought of an alternative that
doesn'
Hey Claes and Peter,
> I'm somewhat strapped for cycles right now, so do you mind if I move ahead
> with the simpler patch Christoph proposed initially (and which Joel has
> already reviewed)?
unsurprisingly I'd go for the simple patch. It's even small enough to have it
backported in my opinion.
16 matches
Mail list logo
