Re: Value types - compatibility with existing “value objects”

[Vitaly Davidovich]

And by the way, .NET had a similar problem.  What they did was change their
lock APIs to indicate whether the lock was obtained or not using a by-ref
boolean.  So your code would now look like (pseudo java code assuming
by-ref passing capability):

boolean locked = false;
try {
   lock.lock(ref locked);
} finally {
   if (locked) {
     lock.unlock();
  }
}

This way you can get yourself inside the protected try region when
performing the action.

On Fri, Jan 9, 2015 at 9:14 AM, Vitaly Davidovich <vitalyd at gmail.com> wrote:

> I think some of that true.  For example, a lot of lock code looks like:
>
> lock.lock();
> try {
> ...
> } finally {
>  lock.unlock();
> }
>
> If the lock implementation causes SOE or OOM as part of lock() and yet
> acquires the lock in the process, then yes, you're hosed.  This is a
> quality of implementation issue.  Someone can also abort the thread right
> after the lock is acquired but before you enter the try region.
> Thankfully, people are discouraged from doing that and you don't tend to
> see this in the wild.
>
> In terms of finally blocks not being executed, I don't think that's true
> (modulo JVM crashing) if the SOE was thrown from within a try/catch block.
> The JVM intentionally reserves some space at the tail of the stack to leave
> room for itself to initiate unwinding.
>
>
>
>
> On Fri, Jan 9, 2015 at 9:01 AM, Simon Ochsenreither <
> simon at ochsenreither.de> wrote:
>
>> > Worth mentioning that SOE is infinitely more recoverable than heap OOME.
>> >  In the latter case (especially with complex systems, where the risk is
>> > ironically even higher of it happening) there's often not much you can
>> > do other than kill off the JVM and try again.  But if you run out of
>> > stack, everything should unwind in a very predictable (and fast) manner.
>> >  You could even automatically rebuild your thread pools with larger
>> > stack sizes fairly easily.
>>
>> Your VM might be broken after both. SOE is definitely not recoverable.
>> Yes, it might work, but no guarantees it does.
>>
>> Money quote: "You will find occurrences of StackOverflowError leaving
>> locks locked, monitors acquired, and "finally" block not invoked, even
>> if JVM doesn't crash."
>>
>> Maybe things have changed since then?
>>
>
>