+1, nice fix.
> -Original Message-
> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf
> Of Joe Wang
> Sent: Mittwoch, 17. August 2016 18:30
> To: Aleks Efimov
> Cc: core-libs-dev
> Subject: Re: RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static
>
Hi Tagir,
Hmm… we certainly ensure that any short-circuiting computation will wait until
all the computation is complete (tasks still running whose results will be
thrown away have to complete before the terminal operation returns).
In that sprit we should be consistent when exceptions are thro
Hi,
please review this change which adds pre-generation of simple
DelegatingMethodHandles corresponding to the DirectMethodHandles we
already pre-generate during linking.
webrev: http://cr.openjdk.java.net/~redestad/8164044/webrev.02/
bug: https://bugs.openjdk.java.net/browse/JDK-8164044
Thi
Brent,
hotspot/src/share/vm/prims/stackwalk.cpp:
230 if (!expressions &&
231 values->at(i)->type() == T_INT &&
232 values->int_at(i) == 0 && // empty first slot of long?
233 i+1 < values->size() &&
234 values->at(i+1)->type() == T_INT) {
How does this tes
Hi,
Please review this StackWalker fix in hotspot for 8156073, "2-slot
LiveStackFrame locals (long and double) are incorrect"
Bug: https://bugs.openjdk.java.net/browse/JDK-8156073
Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.01/
The experimental LiveStackFrame[1] interface for
> On 16 Aug 2016, at 20:08, Tagir F. Valeev wrote:
>
> Hello, Paul!
>
> Thank you. Here's issue:
> https://bugs.openjdk.java.net/browse/JDK-8164189
> And webrev:
> http://cr.openjdk.java.net/~tvaleev/webrev/8164189/r1/
>
Thanks will push today or tomorrow,
Paul.
> With best regards,
> Tagir
On 8/16/16 8:33 PM, Mandy Chung wrote:
On Aug 16, 2016, at 1:54 PM, Brent Christian wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-7180225
Webrev: http://cr.openjdk.java.net/~bchristi/7180225/webrev.01/webrev/
Specdiff:
http://cr.openjdk.java.net/~bchristi/7180225/webrev.01/specdi
Looks good, Aleksej. Thanks for coming up with a well-thought solution
to get rid of the static RE field.
Best,
Joe
On 8/17/16, 7:04 AM, Aleks Efimov wrote:
Hi Joe, Aleksey,
Thank you for reviewing the initial fix.
I followed the Joe's suggestion (thanks for that) and removed static
'abort'
Looks fine to me.
--Sean
On 08/16/2016 02:54 PM, Brent Christian wrote:
Hi,
Please review this change which does some cleanup around documenting
conditions for throwing SecurityExceptions.
It adds a missing @throws tag to Class.forName(String, boolean,
ClassLoader), and consolidates specifics
Hi Joe, Aleksey,
Thank you for reviewing the initial fix.
I followed the Joe's suggestion (thanks for that) and removed static
'abort' field completely, the functionality was replaced by throwing the
exception of newly added type - AbortException. The new webrev with
removed 'abort' can be fou
Hi Kim,
On 08/15/2016 05:15 AM, Kim Barrett wrote:
>I have a feeling that these pauses are now unnecessary. Will try to check with
some experiments…
I found that the DirectBufferAllocTest will sometimes fail if the pauses are
taken out.
I think what’s going on is that the multiple threads ar
Hello!
I found no information in Stream API documentation on how it behaves
in case if exception occurs during the stream processing. While it's
quite evident for sequential stream (stream processing is terminated
and exception is propagated to the caller as is), the behavior for
parallel streams
Hi Peter,
On 17/08/16 12:20, Peter Levart wrote:
Hi Daniel,
Thinking of this patch from the compatibility standpoint, aren't you
afraid that someone might be using the following idiom:
public class MyLevel extends java.util.logging.Level {
static {
new MyLevel("LEVEL1", 1);
On 10/08/2016 23:46, Martin Buchholz wrote:
On Wed, Aug 10, 2016 at 11:52 AM, Paul Benedict
wrote:
Martin, what do you have in mind when saying it's "broken"? Functionally,
everything is fine -- I can delete "release" locally without issue (so it
appears) -- so I imagine there's humor here I
On 08/17/2016 01:20 PM, Peter Levart wrote:
You could use a ClassLoaderValue for this purpose, like in the
following addition to your patch (see KnownLevel.add):
http://cr.openjdk.java.net/~plevart/jdk9-dev/Level.known/webrev.01/
Note that the above also contains the functional-style findLe
On 08/17/2016 01:16 PM, Daniel Fuchs wrote:
Now that you have various findByXXX methods return Optional, you
could make methods that use them more Optional-API-powered. For
example,
findLevel could be written as a single expression:
Right. But do you mind if I leave that for another day?
I'
Hi Daniel,
Thinking of this patch from the compatibility standpoint, aren't you
afraid that someone might be using the following idiom:
public class MyLevel extends java.util.logging.Level {
static {
new MyLevel("LEVEL1", 1);
new MyLevel("LEVEL2", 2);
...
}
Hi Peter,
Now that you have various findByXXX methods return Optional, you
could make methods that use them more Optional-API-powered. For example,
findLevel could be written as a single expression:
Right. But do you mind if I leave that for another day?
I'm not too keen on multi-line code sta
Hi Peter,
Rereading the comment and looking at the code I see
that the comment is actually right. There are two methods
with similar names:
Level.getLocalizedName() which can be overridden by subclasses
and Level.getLocalizedLevelName() which cannot.
By default Level.getLocalizedName() calls Le
On 17.08.2016 01:50, Paul Sandoz wrote:
> On 8 Aug 2016, at 12:14, Patrick Reinhart wrote:
>> Am 08.08.2016 um 18:55 schrieb Alan Bateman :
>>> On 08/08/2016 17:29, Patrick Reinhart wrote:
>>>
:
I tried to integrate your suggested changes here:
http://cr.openjdk.java.net/~reinhapa/r
Hi Mandy,
On 17/08/16 05:05, Mandy Chung wrote:
On Aug 16, 2016, at 5:42 AM, Daniel Fuchs wrote:
>
> Hi Mandy,
>
> I added an additional selector parameter to the find methods.
> This made it possible to return Optional instead of
> KnownLevel - and it does simply the parse() method.
>
> http:/
21 matches
Mail list logo