By: Tzvetan Mikov (tmikov.delete@this.gmail.com), October 19, 2006 4:08 pm
Room: Moderated Discussions
Ricardo B (ricardo.b@xxxxx.xx) on 10/19/06 wrote:
---------------------------
>Tzvetan Mikov (tmikov@gmail.com) on 10/19/06 wrote:
>---------------------------
>>That's not the point at all. Sorry if I wasn't clear.
>>That kind of thing can cause the JVM to crash. A programming error in a safe language
>>isn't supposed to be able to do that.
>
>Ah..
>
>JVMs are supposed to be implemented in such way that such code doesn't crash them.
>Are you assuming you can crash a JVM with such code?
No, I assume that this is handled. That's why I wonder whether the unavoidable memory barrier after every allocation is a serious bottleneck.
The promise of garbage collected languages, especially functional ones like ML, is that memory allocation is extremely efficient - comparable to a stack push. It turns out that this is impossible, even if threads use local allocation pools.
For exampple, Andrew Appel's books about compiling ML (and other compiler construction books), while very good IMO, completely ignore the subject of multi-threading.
>As for costs, on x86(-64), normal stores already have strong ordering semantics.
Don't you agree that the great unifier, x86, makes all sorts of discussions less interesting ? :-)
The conclusion that x86 is a more suitable target for safe languages than other more agressive architectures is an intriguing and somewhat unexpected one. It adds additional weight to the opinion that Linus has shared many times on this forum.
>>(A smaller secondary point is that the Java libraries distributed by Sun have this
>>bug, but that is really a different and not that interesting subject)
>
>It's only a bug if m_cachedResult isn't declared as volatile. Is it?
Well, it isn't in a library which I am looking at right now, which admittedly is not Sun's. I remember seeing this pattern several times in the JDK code, but I am not completely sure whether the declarations were volatile or not. My intent is not to track down such bugs or to submit reports to Sun (although I will when I see one).
The "broken thread-safe singleton" pattern is sufficiently well known, so that few people make the mistake of using it any more. However this case looks superficially different, so it appears to be still in wide use.
---------------------------
>Tzvetan Mikov (tmikov@gmail.com) on 10/19/06 wrote:
>---------------------------
>>That's not the point at all. Sorry if I wasn't clear.
>>That kind of thing can cause the JVM to crash. A programming error in a safe language
>>isn't supposed to be able to do that.
>
>Ah..
>
>JVMs are supposed to be implemented in such way that such code doesn't crash them.
>Are you assuming you can crash a JVM with such code?
No, I assume that this is handled. That's why I wonder whether the unavoidable memory barrier after every allocation is a serious bottleneck.
The promise of garbage collected languages, especially functional ones like ML, is that memory allocation is extremely efficient - comparable to a stack push. It turns out that this is impossible, even if threads use local allocation pools.
For exampple, Andrew Appel's books about compiling ML (and other compiler construction books), while very good IMO, completely ignore the subject of multi-threading.
>As for costs, on x86(-64), normal stores already have strong ordering semantics.
Don't you agree that the great unifier, x86, makes all sorts of discussions less interesting ? :-)
The conclusion that x86 is a more suitable target for safe languages than other more agressive architectures is an intriguing and somewhat unexpected one. It adds additional weight to the opinion that Linus has shared many times on this forum.
>>(A smaller secondary point is that the Java libraries distributed by Sun have this
>>bug, but that is really a different and not that interesting subject)
>
>It's only a bug if m_cachedResult isn't declared as volatile. Is it?
Well, it isn't in a library which I am looking at right now, which admittedly is not Sun's. I remember seeing this pattern several times in the JDK code, but I am not completely sure whether the declarations were volatile or not. My intent is not to track down such bugs or to submit reports to Sun (although I will when I see one).
The "broken thread-safe singleton" pattern is sufficiently well known, so that few people make the mistake of using it any more. However this case looks superficially different, so it appears to be still in wide use.