ev-boun...@openjdk.java.net] On
> Behalf Of Frederic Parain
> Sent: Montag, 14. Dezember 2015 14:24
> To: Karen Kinnear
> Cc: hotspot-...@openjdk.java.net; core-libs-dev d...@openjdk.java.net>
> Subject: Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical
>
; Karen Kinnear
>
> Cc: hotspot-...@openjdk.java.net; core-libs-dev d...@openjdk.java.net>
> Subject: Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical
> Sections
>
> Goetz,
>
> The reserved zone is sometime considered as a subpart of
> the yellow zone, a
est regards,
Goetz.
-Original Message-
From: hotspot-dev [mailto:hotspot-dev-boun...@openjdk.java.net] On
Behalf Of Frederic Parain
Sent: Montag, 14. Dezember 2015 14:24
To: Karen Kinnear
Cc: hotspot-...@openjdk.java.net; core-libs-dev
Subject: Re: RFR(L): JDK-8046936 : JEP 270: Re
ain
Sent: Montag, 14. Dezember 2015 14:24
To: Karen Kinnear
Cc: hotspot-...@openjdk.java.net; core-libs-dev
Subject: Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical
Sections
Karen,
Thank you for your review.
Fred
On 23/11/2015 20:10, Karen Kinnear wrote:
Frederic,
Loo
Karen,
Thank you for your review.
Fred
On 23/11/2015 20:10, Karen Kinnear wrote:
Frederic,
Looks good.
Many thanks.
Karen
On Nov 23, 2015, at 12:44 PM, Frederic Parain
mailto:frederic.par...@oracle.com>> wrote:
Karen,
Thank you for your review, my answers are in-lined below.
New Webrevs
On 6/12/2015 2:23 AM, Doug Lea wrote:
On 12/03/2015 12:53 AM, David Holmes wrote:
On 3/12/2015 12:56 AM, Doug Lea wrote:
In the absence of any of: tail-recursion support, reliable cleanup,
or growable stacks, it seems reasonable to choose larger default
stack sizes so that these long but finite
On 12/03/2015 12:53 AM, David Holmes wrote:
On 3/12/2015 12:56 AM, Doug Lea wrote:
In the absence of any of: tail-recursion support, reliable cleanup,
or growable stacks, it seems reasonable to choose larger default
stack sizes so that these long but finite chains of completions
are far less lik
All fixed.
Thank you Dan.
Fred
On 02/12/2015 19:22, Daniel D. Daugherty wrote:
On 12/1/15 9:21 AM, Frederic Parain wrote:
Hi Dan,
Thank you for your detailed review.
My answers are in-lined below.
New webrev:
http://cr.openjdk.java.net/~fparain/8046936/webrev.02/hotspot/
Re-reviewed by
On 3/12/2015 12:56 AM, Doug Lea wrote:
Bringing Martin's JEP comment
(https://bugs.openjdk.java.net/browse/JDK-8046936)
to the lists:
Approximately 100% of the cases of StackOverflowError (SOE) we
hear about lately on concurrency-interest are due to long chains
of CompletableFutures that exist
On 12/1/15 9:21 AM, Frederic Parain wrote:
Hi Dan,
Thank you for your detailed review.
My answers are in-lined below.
New webrev:
http://cr.openjdk.java.net/~fparain/8046936/webrev.02/hotspot/
Re-reviewed by comparing 8046936.0[12].hotspot.patch in jfilemerge...
Just a couple of nits:
src
On 12/02/2015 02:56 PM, Doug Lea wrote:
> On 32bit systems the 1MB limit is completely defensible. But expanding
> to say 64MB on 64bit systems would reduce practical encounters with
> SOE in these kinds of constructions by a factor of 64 or so.
> Is there any reason not to do this?
Some cloud VM
Bringing Martin's JEP comment (https://bugs.openjdk.java.net/browse/JDK-8046936)
to the lists:
Approximately 100% of the cases of StackOverflowError (SOE) we
hear about lately on concurrency-interest are due to long chains
of CompletableFutures that exist because of the lack of
tail-recursion lo
Hi Dan,
Thank you for your detailed review.
My answers are in-lined below.
New webrev:
http://cr.openjdk.java.net/~fparain/8046936/webrev.02/hotspot/
On 24/11/2015 17:26, Daniel D. Daugherty wrote:
src/cpu/sparc/vm/frame_sparc.cpp
(old) L635: if (fp() - sp() > 1024 +
m->max_stack()*I
Considering stack overflow as fatal errors makes sense for
JVM running single applications. This could be the subject
of a RFE, the feature is well defined and the implementation
should not be too complex.
However, JEP-270 has been designed with multi-tenant applications
in mind. In this context,
On 11/23/15 10:44 AM, Frederic Parain wrote:
Karen,
Thank you for your review, my answers are in-lined below.
New Webrevs (including some fixes suggested by Paul Sandoz):
http://cr.openjdk.java.net/~fparain/8046936/webrev.01/hotspot/
src/cpu/sparc/vm/frame_sparc.cpp
(old) L635: if (fp(
On Nov 24, 2015, at 8:46 AM, Karen Kinnear wrote:
> Doug,
>
> I have been thinking about this more from the perspective of the original
> problem
> we set out to solve
I apologize if this has already been considered -- but for a lot well designed
systems,
occasional application failure is an
Doug,
I have been thinking about this more from the perspective of the original
problem
we set out to solve, which was identified in the concurrent hash map usage, at
the
time in the class loading logic. While the class loading logic has changed, I
think we
have enough experience with this part
Frederic,
Looks good.
Many thanks.
Karen
> On Nov 23, 2015, at 12:44 PM, Frederic Parain
> wrote:
>
> Karen,
>
> Thank you for your review, my answers are in-lined below.
>
> New Webrevs (including some fixes suggested by Paul Sandoz):
>
> http://cr.openjdk.java.net/~fparain/8046936/webrev
Karen,
Thank you for your review, my answers are in-lined below.
New Webrevs (including some fixes suggested by Paul Sandoz):
http://cr.openjdk.java.net/~fparain/8046936/webrev.01/hotspot/
http://cr.openjdk.java.net/~fparain/8046936/webrev.01/jdk/
On 20/11/2015 19:44, Karen Kinnear wrote:
Fre
On 11/20/2015 12:40 PM, Karen Kinnear wrote:
Totally appreciate the suggestion that the java.util.concurrent modifications
be done by folks with more domain expertise.
Would you have us incorporate the initial minimal set of j.u.c. updates or none
at all?
Sorry that I'm still in foot-drag mode
Frederic,
Code review for web revs you sent out.
Code looks good. I am not as familiar with the compiler code.
I realize you need to check in at least a subset of the java.util.concurrent
changes for
the test to work, so maybe I should not have asked Doug about his preference
there.
Sorry.
I a
Totally appreciate the suggestion that the java.util.concurrent modifications
be done by folks with more domain expertise.
Would you have us incorporate the initial minimal set of j.u.c. updates or none
at all?
thanks,
Karen
> On Nov 11, 2015, at 8:09 PM, Doug Lea wrote:
>
> On 11/10/2015 12:
One other example is an unlock that requires three steps - update state, update
owner and
unpark successor.
thanks,
Karen
> On Nov 19, 2015, at 9:25 PM, David Holmes wrote:
>
> On 20/11/2015 4:10 AM, Doug Lea wrote:
>> On 11/16/2015 08:00 PM, David Holmes wrote:
I've tried that :-) The am
David,
On 17/11/2015 02:00, David Holmes wrote:
Another issue is that writing a rule for javac that is not
overpessimistic is also an intractable problem. The pattern
"atomic operation followed by method invocation to complete
status update" is too general to be the trigger of the annotation.
1)
On 20/11/2015 4:10 AM, Doug Lea wrote:
On 11/16/2015 08:00 PM, David Holmes wrote:
I've tried that :-) The amount of code being executed with
the ReservedStackAccess privilege tends to increase very
quickly and I was concerned about keeping the size of the
reserved area small.
How much space d
On 11/16/2015 08:00 PM, David Holmes wrote:
I've tried that :-) The amount of code being executed with
the ReservedStackAccess privilege tends to increase very
quickly and I was concerned about keeping the size of the
reserved area small.
How much space does each level of calling need? I know t
Hi Fred,
On 11/11/2015 3:38 AM, frederic parain wrote:
Hi David and Doug,
Thank you for your feedback.
I put some comments below.
On 09/11/2015 08:12, David Holmes wrote:
Hi Doug,
On 9/11/2015 9:31 AM, Doug Lea wrote:
On 11/06/2015 02:23 AM, David Holmes wrote:
Before I look at the code,
On 11/10/2015 12:38 PM, frederic parain wrote:
If I put on some extra-strength rose-coloured glasses I think I can
almost read that as "something is better than nothing". ;-)
Yeah, that's what I meant :-) It is good to at least have the
@ReservedStackAccess annotation and mechanism in place. F
Hi David and Doug,
Thank you for your feedback.
I put some comments below.
On 09/11/2015 08:12, David Holmes wrote:
Hi Doug,
On 9/11/2015 9:31 AM, Doug Lea wrote:
On 11/06/2015 02:23 AM, David Holmes wrote:
Before I look at the code, what is the status of the "Open Issues"
referenced in th
Hi Doug,
On 9/11/2015 9:31 AM, Doug Lea wrote:
On 11/06/2015 02:23 AM, David Holmes wrote:
Before I look at the code, what is the status of the "Open Issues"
referenced in the JEP?
Also the JDK changes need to be reviewed on core-libs-dev and in
particular must
be seen by the jsr166 maintaine
On 11/06/2015 02:23 AM, David Holmes wrote:
Before I look at the code, what is the status of the "Open Issues" referenced in
the JEP?
Also the JDK changes need to be reviewed on core-libs-dev and in particular must
be seen by the jsr166 maintainers (ie Doug Lea and Martin Buchholz)
Martin an
31 matches
Mail list logo
