Hopefully, I've got Cliff's email addresses sorted out so his
submissions won't bounce anymore.
At 1:32 PM -0400 8/22/01, Cliff Click wrote:
> > > Sun's certainly gone to some length to make sure StackOverflowError
>> > appears to be thrown at some particular point. InternalErrors are
>> > never thrown because we don't have recoverable errors; i.e. the VM
>> > crashes instead. :-)
>>
> > The JLS (in 11.3.1 and 11.3.2) requires precision for all Errors, even
>> InternalError, which is the only asynchronous Error which can be thrown
>> by the VM. (A side issue is that there is *no* apparent circumstance
>> under which UnknownError can be thrown, unless it is perhaps intended to
>> be a synchronous form of InternalError.)
>
>
>Right, StackOverflowError is thrown precisely. InternalError isn't
>thrown (but see next email on MappedByteBuffers) from normal Java code.
>Not sure if this has anything to do with JMM.
>
>Cliff
At 1:37 PM -0400 8/22/01, Cliff Click wrote:
> > Is that right? On JSR 51 we went to some lengths to squeeze a
>> promise out of the Hotspot team that reads or writes of
>> MappedByteBuffers whose underlying mmap'd file had been truncated
>> out from under them would result in some (not necessarily very
>> precise) InternalError being thrown eventually, rather than having the
>> VM exit on a signal.
>>
>> Have I misunderstood what's going on in this case?
>
>I wrote too aggressively: we indeed throw an IMprecise InternalError
>if you are using the Unsafe classes to access outside the heap and
>the mmap'd file gets truncated. When you use Unsafe you step outside
>the bounds of the Java model and lose the benefits thereof (i.e.,
>precise exceptions) and perhaps gain something else in return (i.e.,
>high performance I/O).
>
>Again, not sure what this has to do with the JMM.
>
>Cliff
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:34 EDT