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 particular example and have studied the code constructs sufficiently that there is value in checking in the small set of JDK changes that target that situation. I also think this gives a sample of the kind of model in which this approach can be effective. In addition, having this small set of changes provides the ability to test and ensure that the hotspot changes continue to work.
So I would like to recommend that we go ahead and check in the hotspot changes and the initial minimal set of j.u.c. updates as a way to put the new mechanism in place so that the people with more domain expertise in the java.util.concurrent libraries can experiment with the mechanism and add incremental improvements. thanks, Karen > On Nov 22, 2015, at 7:04 PM, Doug Lea <d...@cs.oswego.edu> wrote: > > 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 on this. > Reading David and Fred's exchanges reinforce my thoughts > that there is no defensible rule or approach to > use @ReservedStackAccess so as to add as little time and > space as possible to reduce the occurrence of stuck > resources as much as possible during StackOverflowError. > > After googling "StackOverflowError java util concurrent" and seeing the > range of situations that can be encountered, I don't even know > which kinds of constructions to target. > And I'm less sure whether using @ReservedStackAccess at all > is better than doing nothing. > > Maybe there is some decent empirical strategy, but I can't > tell until hotspot support of @ReservedStackAccess is in place. > So my vote is still to keep the JDK changes out for now. > > -Doug >
