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 and I and others are aware of this work.
As has been said by everyone initially looking at JEP 270,
it is a disappointing effort. It requires that APIs/methods supporting
try/finally-like constructions (especially locks) include new annotations to
substantially reduce the likelihood of failing to perform the "finally" side
actions to release resources (like a lock) upon StackOverflowError.
Considering that no other readily implementable solution has
been proposed during the many years that this issue has been discussed,
a disappointing band-aid might not be so bad.
Assuming the hotspot mechanics are put into place, the main question
is when to use the @ReservedStackAccess annotation.
The JEP singles out ReentrantLock. But there are also other locks
provided in JDK (StampedLock, ReentrantReadWriteLock), as well
as in other external packages, that should probably use this.
Plus there are other lock/resource APIs, for example Semaphore,
that are often used in try/finally constructions. And internal
before/after bookkeeping inside Executors. Plus, many cases of
try-with-resources constructions. Plus many transactional APIs.
And so on. It would be a never-ending effort to effectively use
@ReservedStackAccess.
I don't know of a good way to address this. One possibility is
for javac to automatically insert @ReservedStackAccess in any
method with a try-finally that involves at least one call?
-Doug
On 6/11/2015 12:17 AM, Frederic Parain wrote:
Please review the changesets for JEP 270: Reserved Stack Areas for
Critical Sections
CR: https://bugs.openjdk.java.net/browse/JDK-8046936
Webrevs:
hotspot: http://cr.openjdk.java.net/~fparain/8046936/webrev.00/hotspot/
JDK: http://cr.openjdk.java.net/~fparain/8046936/webrev.00/jdk/
The CR contains a detailed description of the issue and the design
of the solution as well as implementation details.
Tests:
JPRT - hotspot & core
RBT - vm.quick
Thanks
Fred
