RE: JEP 193: Enhanced Volatiles
David Holmes wrote: But if the JVM acts upon annotations to change how it executes those bytecodes then, as Peter said, the JVM is implementing the language semantics. The JVM synthesizes a native method, this has *nothing* to do with language semantics. From the language point of view, native method implementations magically appear. This is just another instance of that. Regards, Jeroen
Re: RFR: (s) 8036095: RMI tests using testlibrary.RMID and testlibrary.JavaVM do not pass through vmoptions
On 05/03/2014 22:05, Stuart Marks wrote: Hi all, Please review this fix to change RMI's test library to pass through vmoptions and javaoptions to rmid and other JVM subprocesses. I've marked this as a small review because the changes of substance are confined to the first four files in the webrev, and they're pretty small. The remaining changes are to the individual security.policy files of each test, which requires different permissions granted in order to allow reading of the test.vm.opts and test.java.opts properties. Webrev: http://cr.openjdk.java.net/~smarks/reviews/8036095/webrev.0/ I've looked through the changes and they look okay to me. I also grabbed the patch and ran the jdk_rmi tests with a few XX options specific to jtreg via -vmoption and it works. Just on David's comment then I think it would be surprising to specify options to jtreg but have some but not all tests use it consistently. There have been a number of passes over the shell tests to make sure that VM options are passed through but there is still work required to check tests that use Runtime.exec or ProcessBuilder to start other VMs to see that they pass through the expected options. As to whether someone would run these tests with -Xcomp or other stress options then I don't know but if they do then it would be strange for some tests to use it and not others. -Alan
Re: RFR (JAXP): 8035577: Xerces Update: impl/xpath/regex/RangeToken.java
On 05/03/2014 22:17, huizhe wang wrote: On 3/5/2014 1:38 PM, Alan Bateman wrote: On 05/03/2014 20:18, David Li wrote: Hi, This is an update from Xerces for file impl/xpath/regex/TokenRange.java. For details, please refer to: https://bugs.openjdk.java.net/browse/JDK-8035577. Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/ No new tests. There were none added in Xerces. Existing tests: JAXP SQE and unit tests passed. Do you know if these tests exercise this code? I realize the Xerces didn't come with tests but I do have a concern about changing regex code without knowing that it is at least exercised by some tests. There are over 100 tests in SQE suite in this area, we'll take a look. If you can check then that would be good as I think I can be forgiven for being nervous about bringing in patches that don't have tests. -Alan.
Re: JEP 193: Enhanced Volatiles
On 03/06/2014 01:24 AM, David Holmes wrote: On 6/03/2014 3:22 AM, Remi Forax wrote: On 03/05/2014 06:07 PM, Peter Levart wrote: On 03/05/2014 05:55 PM, Jeroen Frijters wrote: Brian Goetz wrote: I suspect you were expecting this response: we don't add language semantics through annotations. Technically, we're not adding language semantics. The JVM is the one interpreting the annotations. And the JVM is the one implementing the language semantics (together with javac which feeds the JVM with bytecodes). Language semantcis are implemented by the combination of javac and JVM. If you say that this feature does not require any change to javac, you're just saying that you put all the burden on the JVM, but you *are* implementing the language semantics using annotations nevertheless... no, it's the other way around. javac maps Java the language to the bytecode semantics. The JVM only execute bytecodes. But if the JVM acts upon annotations to change how it executes those bytecodes then, as Peter said, the JVM is implementing the language semantics. no, there is no bytecode in the proposal of Jeroen. You can see it has an extended way to call in a VM intrinsic, currently in Hotspot, you have to provide the class name, the method name and the signature to consider a method as an intrinsic. The mechanism proposed by Jeroen is a little bit more general. Moreover, the proposal is interesting because the signature of the native method is under the control of the user so unlike Unsafe equivalent the signature can be verified when the native method is linked making the method safer than their unsafe equivalent. It is also a bit misleading to say that the JVM only executes bytecodes, as the semantics of those bytecodes were driven by the requirements of the language. javac + jvm do form a team here. Most of the bytecodes are standard opcodes, but you're right that some of them like method calls, instance creation or to a lesser extent get[put]Field/get[put]Static have the Java semantics bolt in, that's why we have invokedynamic (and Unsafe.get/put) BTW. David Rémi Regards, Peter cheers, Rémi I'm not trying to frustrate you; evolving a language with millions of users is really, really hard. And one of the things that makes it hard is recognizing our intrinsic conflicts of interest between what good will this do me and what harm will it do others. I understand, that's why I want to avoid adding language support for this niche/specialist feature. Regards, Jeroen
Re: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods
On 04/03/2014 15:32, David M. Lloyd wrote: On 03/03/2014 09:45 PM, David Holmes wrote: We should not introduce anything that allows something that was guaranteed to be safe by the language, to become unsafe. Define 'safe'. Because I don't think it's unsafe, any more than I believe even in the Java library it is common where a publicly accessible monitor is used to safeguard the integrity of security critical datastructures. Where monitorexit to become freely available, that would almost certainly be exploitable. (Technically I believe the JVM spec does (or did) allow unmatched locking in some circumstances, but implementations really shouldn't.) Tom
Re: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods
On 03/06/2014 08:48 AM, Tom Hawtin wrote: On 04/03/2014 15:32, David M. Lloyd wrote: On 03/03/2014 09:45 PM, David Holmes wrote: We should not introduce anything that allows something that was guaranteed to be safe by the language, to become unsafe. Define 'safe'. Because I don't think it's unsafe, any more than I believe even in the Java library it is common where a publicly accessible monitor is used to safeguard the integrity of security critical datastructures. Where monitorexit to become freely available, that would almost certainly be exploitable. I would expect that in a security-critical section, such monitors would be private, else they could be exploited in other ways. -- - DML
Re: JEP 193: Enhanced Volatiles
On 03/05/2014 01:05 AM, Doug Lea wrote: On 03/04/2014 05:12 PM, Florian Weimer wrote: On 03/04/2014 01:05 PM, Doug Lea wrote: On 03/04/2014 02:41 AM, Jeroen Frijters wrote: I understand pass-by-reference is an expensive feature, but IMNSHO poluting Java with this proposal will prove to be more expensive in the long run. It's like erased generics all over again. The expensive version of pass-by-reference is already supported using java.lang.reflect.Field. And per the statistics posted in http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-March/025531.html, the slightly faster pointer-to-field-member support is one of the prevalent use cases for sun.misc.Unsafe. That's why I share Jeroen's puzzlement. Sorry, I'm not sure what usages you have in mind, or what constructions and implementable JVM mechanics could be used to deal with them? If we had lightweight pointer-to-fields, things like compare-and-swap could be implemented as regular intrinsics. It would require less magic syntax, and make it clear that the operations only work with non-static fields and not on local variables etc. It would be possible to write functions that apply a complex sequence of updates to a field, which is impossible under the current proposal. (One aspect I like about Java is that is fairly uniform, e.g., that you can take a subexpression and turn it into a function, or that you can store intermediate results, something that is often impossible in Ada or C++). Pointer-to-fields could be as lightweight as a single integer (they are in C++ and with sun.misc.Unsafe), assuming that the VM enforces type safety. Whether it is a good idea to add another generic type at the VM level before the arrival of reified generics, is a different matter. -- Florian Weimer / Red Hat Product Security Team
RFR: 8036786: Update jdk7 testlibrary to match jdk8
Please review this change to update jdk part of testlibrary in jdk7. It updates testlibrary with new apis from jdk8's testlibrary. When porting jdk8's testlibrary to jdk7, I had to make few changes: 1) rewrite one lambda usage in StreamPumper.java to non-lambda version. 2) get rid of predicate functionality in ProcessTools.java: startProcess as it wasn't used anyway and unsupported in jdk7. Every test in open part of jdk that uses testlibrary still works after update (in fact there are 3 of them). Webrev: http://cr.openjdk.java.net/~vkempik/8036786/webrev.00/ Thanks, Vladimir.
Re: JEP 193: Enhanced Volatiles
What is the interaction with synthetic accessor methods for private fields? Is it not an issue because the field references will be textual anyway, so that no JVM checks will interfere? -- Florian Weimer / Red Hat Product Security Team
Re: JEP 193: Enhanced Volatiles
On 03/06/2014 09:25 AM, Florian Weimer wrote: On 03/05/2014 01:05 AM, Doug Lea wrote: On 03/04/2014 05:12 PM, Florian Weimer wrote: On 03/04/2014 01:05 PM, Doug Lea wrote: On 03/04/2014 02:41 AM, Jeroen Frijters wrote: I understand pass-by-reference is an expensive feature, but IMNSHO poluting Java with this proposal will prove to be more expensive in the long run. It's like erased generics all over again. The expensive version of pass-by-reference is already supported using java.lang.reflect.Field. And per the statistics posted in http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-March/025531.html, the slightly faster pointer-to-field-member support is one of the prevalent use cases for sun.misc.Unsafe. That's why I share Jeroen's puzzlement. Sorry, I'm not sure what usages you have in mind, or what constructions and implementable JVM mechanics could be used to deal with them? If we had lightweight pointer-to-fields, things like compare-and-swap could be implemented as regular intrinsics. It would require less magic syntax, and make it clear that the operations only work with non-static fields and not on local variables etc. It would be possible to write functions that apply a complex sequence of updates to a field, which is impossible under the current proposal. (One aspect I like about Java is that is fairly uniform, e.g., that you can take a subexpression and turn it into a function, or that you can store intermediate results, something that is often impossible in Ada or C++). Pointer-to-fields could be as lightweight as a single integer (they are in C++ and with sun.misc.Unsafe), assuming that the VM enforces type safety. Whether it is a good idea to add another generic type at the VM level before the arrival of reified generics, is a different matter. The proposed interface types *could* be used as such a pointer, with the caveats I've given in another branch, that we'd really want the object allocation to be free or cheap in most cases. It's one construct that is effectively missing from JUC today. There is a updater for field X on any object and updater for *otherwise inaccessible* field X on object Y but there's no updater for field X on object Y. The foo.volatile syntax *could* provide that, though this does run counter to the JEP which indicates that a raw foo.volatile is not by itself a valid expression. But the optimizability of the construct is really the key decision axis as far as I can see; specifically it would have to be able to optimize foo.volatile.xxx() constructs directly to the minimal set of instructions while still allowing foo.volatile to return a real object that can be fiddled with by others. In particular it would be really annoying if you had to manually maintain another field to hold this hypothetical value of foo.volatile to avoid creating a new one every time (though I think it's perfectly reasonable for the JVM to create a hidden field which does this in the case where this value escapes the stack). -- - DML
Re: [7u backport] RFR: 7122142: (ann) Race condition between isAnnotationPresent and getAnnotations
Looks fine to me as well. cheers, dalibor topic On 3/3/14 1:21 PM, dmeetry degrave wrote: Hi all, I would like to ask someone with a reviewer status in jdk7u project to look at these changes. thanks, dmeetry On 02/27/2014 05:44 PM, Joel Borggren-Franck wrote: Hi, I looked at webrev.1. Looks good. cheers /Joel On 2014-02-25, dmeetry degrave wrote: Thanks for looking at this, Peter! On 02/24/2014 04:42 PM, Peter Levart wrote: Hi Dmeetry, On 02/22/2014 01:22 PM, dmeetry degrave wrote: Hi all, I would like to ask for a review of combined back port for 7u-dev/7u80. The main goal is to have a fix for 7122142 in jdk7, it also integrates the changes from 8005232, 7185456, 8022721 https://bugs.openjdk.java.net/browse/JDK-7122142 https://bugs.openjdk.java.net/browse/JDK-8005232 https://bugs.openjdk.java.net/browse/JDK-7185456 https://bugs.openjdk.java.net/browse/JDK-8022721 Original jdk8 changes: 7122142: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4ce6502eac0 8005232: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1109bfff4e92 7185456: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae03282ba501 8022721: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2281a7f79738 back port: http://cr.openjdk.java.net/~dmeetry/7122142.8005232.7185456.8022721/webrev.0/ Patches can't be applied cleanly, hence it was a manual back port, though the final result is equivalent to applying the patches in chronological order (8005232, 7185456, 7122142, 8022721) and applying all the relevant rejected parts It's good to see those patches being back-ported to 7u. By browsing the webrev, I don't see any obvious difference between the original patches and the backport. there shouldn't be any! Do you happen to remember in what part of code there were rejects so that you had to manually apply the changes? there were conflicts due to small difference between 7 and 8 (copyrights, white spaces, @SuppressWarnings, Class?,...). I copied all rejected parts and original patches here: http://cr.openjdk.java.net/~dmeetry/7122142.8005232.7185456.8022721/webrev.1/rej/ (with one exception, AnnotationTypeRuntimeAssumptionTest.java test was not included due to jdk8 API). Ah, It's the Class.getDeclaredAnnotation(Class) that's new in JDK8. Here's the changed test that only uses the JDK7 API so you can include this test too: http://cr.openjdk.java.net/~plevart/jdk7u/7122142/AnnotationTypeRuntimeAssumptionTest.java Thanks! http://cr.openjdk.java.net/~dmeetry/7122142.8005232.7185456.8022721/webrev.1/ (just with the new test added). thanks, dmeetry All tests in test/java/lang/annotation passed. thanks, dmeetry Regards, Peter -- Oracle http://www.oracle.com Dalibor Topic | Principal Product Manager Phone: +494089091214 tel:+494089091214 | Mobile: +491737185961 tel:+491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. Co. KG | Kühnehöfe 5 | 22761 Hamburg ORACLE Deutschland B.V. Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Geschäftsführer: Jürgen Kunz Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle http://www.oracle.com/commitment Oracle is committed to developing practices and products that help protect the environment
Re: RFR (JAXP): 8035577: Xerces Update: impl/xpath/regex/RangeToken.java
On 3/6/2014 12:31 AM, Alan Bateman wrote: On 05/03/2014 22:17, huizhe wang wrote: On 3/5/2014 1:38 PM, Alan Bateman wrote: On 05/03/2014 20:18, David Li wrote: Hi, This is an update from Xerces for file impl/xpath/regex/TokenRange.java. For details, please refer to: https://bugs.openjdk.java.net/browse/JDK-8035577. Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/ No new tests. There were none added in Xerces. Existing tests: JAXP SQE and unit tests passed. Do you know if these tests exercise this code? I realize the Xerces didn't come with tests but I do have a concern about changing regex code without knowing that it is at least exercised by some tests. There are over 100 tests in SQE suite in this area, we'll take a look. If you can check then that would be good as I think I can be forgiven for being nervous about bringing in patches that don't have tests. Understand. We'll look into adding new tests. -Joe -Alan.
Review 8035808: Eliminate dependency to GetPropertyAction and other sun.security.action convenient classes
Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035808/webrev.00/ This patch converts the use of sun.security.action.GetPropertyAction tolambda (PrivilegedActionString) () - System.getProperty(key) Similarly for GetIntegerAction and GetLongAction. The sun.security.action.* classes are just convenient classes that are used not only by the security library but also used by RMI, management, a couple other components that cause cross-module dependency that are not absolutely necessary. They can simply be replaced to call System.getProperty, Integer.getInteger, or Long.getLong at the callsite. Mandy
