JSR166与reorder,compiler的疑惑

runshine 2013-12-19
J.U.C包的JavaDoc中,在原有的happen-before规则上又新增了一组happen-before规则。那么为了保证这组规则,是不是意味着编译器(比如javac、JIT)开发者要对J.U.C包下的类做特别对待?
(虽然R大您跟我说过“好多年之前开始Java源码编译到class文件的源码级编译器就已经不做重排序了。不是理论上不能做,只是投入-收益比不高所以大家都不做了而已。”,这里不考虑这个。)

=============================
如果我写个ReentrantLock2,这个类只是将原ReentrantLock的内容拷贝过来,ReentrantLock2内部不使用AbstractQueuedSynchronizer,同样是使用一个拷贝了其内容的AbstractQueuedSynchronizer2,其它以此类推...
那这个ReentrantLock2能顺利的作为一个遵循了JSR133的锁的实现么?

=============================
《Threads Cannot be Implemented as a Library》:http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html 看不动... 似乎也是在说如果没有语言规范的限制以及与编译器之间的约定很难通过库来实现正确的多线程?
RednaxelaFX 2013-12-19
j.u.c在Oracle/OpenJDK里的实现是用了sun.misc.Unsafe里的一些方法来实现原子操作和锁等功能。这些Unsafe方法在VM里是有特殊实现的。只要您的ReentrantLock2也使用一样的Unsafe方法就能得到同样的特殊处理。但如果可以的话尽量不要直接用Unsafe方法,而应该至少用j.u.c.atomic系的包装。
runshine 2013-12-19
RednaxelaFX 写道
j.u.c在Oracle/OpenJDK里的实现是用了sun.misc.Unsafe里的一些方法来实现原子操作和锁等功能。这些Unsafe方法在VM里是有特殊实现的。只要您的ReentrantLock2也使用一样的Unsafe方法就能得到同样的特殊处理。但如果可以的话尽量不要直接用Unsafe方法,而应该至少用j.u.c.atomic系的包装。


谢谢
Unsafe的那些我也猜测过VM会特别处理
所以特别提到了javac
如果某个人实现javac,并且在这一层上就做指令重排(虽然您说过现在几乎没这么做的了),是不是需要关注JUC的这些?
不然在源码到字节码这一层
Lock.lock()
operationA()
operationB()
Lock.unlock()
被重排成
operationA()
Lock.lock()
Lock.unlock()
operationB()
似乎也是有可能的

这两天看完了《JC in P》还有参考了JSR133FAQ中“What if I'm writing a VM?”http://gee.cs.oswego.edu/dl/jmm/cookbook.html
其中都只是对语言中的关键字做的约束,都没有强调JUC包的情况。
之前似乎看到过您有说VM对RuntimeException有特别对待(帖子没能找到),而产生了这个联想——感觉javac,JIT,VM这几层如果做某些优化的话,需要特别对待JSR166的这一系列东西
RednaxelaFX 2013-12-19
runshine 写道
Unsafe的那些我也猜测过VM会特别处理
所以特别提到了javac
如果某个人实现javac,并且在这一层上就做指令重排(虽然您说过现在几乎没这么做的了),是不是需要关注JUC的这些?
不然在源码到字节码这一层
Lock.lock()
operationA()
operationB()
Lock.unlock()
被重排成
operationA()
Lock.lock()
Lock.unlock()
operationB()
似乎也是有可能的

嗯,javac(或者其它Java源码编译器)如果做优化的话得考虑到不重排j.u.c里的一些方法调用的代码。现在反正javac也不做优化所以也就没啥可烦的。
但通常来说,编译器会认为方法调用是一种有潜在副作用的操作,副作用可能修改内存状态。进一步的,方法调用的前后的代码就不能乱移动了。如果内联了的话就另当别论。

runshine 写道
这两天看完了《JC in P》还有参考了JSR133FAQ中“What if I'm writing a VM?”http://gee.cs.oswego.edu/dl/jmm/cookbook.html
其中都只是对语言中的关键字做的约束,都没有强调JUC包的情况。
之前似乎看到过您有说VM对RuntimeException有特别对待(帖子没能找到),而产生了这个联想——感觉javac,JIT,VM这几层如果做某些优化的话,需要特别对待JSR166的这一系列东西

VM对RuntimeException的特殊对待?什么方面?
runshine 2013-12-19
RednaxelaFX 写道
VM对RuntimeException的特殊对待?什么方面?


诶?我印象中就是您的一篇文章提到的啊...
不过搜索论坛也确实没能找到,我幻觉了?

记得好像是有人问为什么都继承自Exception,唯独RuntimeException及其子类可以不用捕获...您提到是因为对它是特别对待的
RednaxelaFX 2013-12-19
runshine 写道
记得好像是有人问为什么都继承自Exception,唯独RuntimeException及其子类可以不用捕获...您提到是因为对它是特别对待的

RuntimeException及其子类不用显式捕获确实在javac里有特殊处理。其它方面就没啥了。跟其它异常类型相比,JVM也不需要对RuntimeException做特殊处理。
runshine 2013-12-19
RednaxelaFX 写道
RuntimeException及其子类不用显式捕获确实在javac里有特殊处理。其它方面就没啥了。跟其它异常类型相比,JVM也不需要对RuntimeException做特殊处理。


噢噢...原来是javac这一层  多谢多谢
Global site tag (gtag.js) - Google Analytics