Re: RFR: 8288140: Avoid redundant Hashtable.get call in Signal.handle [v2]

2022-06-10 Thread David M . Lloyd
On Fri, 10 Jun 2022 06:45:00 GMT, Jaikiran Pai wrote: >> src/java.base/share/classes/jdk/internal/misc/Signal.java line 180: >> >>> 178: if (newH == 2) { >>> 179: handlers.put(sig, handler); >>> 180: } >> >> If you made this change instead: >> >> Suggest

Re: RFR: 8288140: Avoid redundant Hashtable.get call in Signal.handle

2022-06-09 Thread David M . Lloyd
On Thu, 9 Jun 2022 07:35:43 GMT, Andrey Turbanov wrote: > https://github.com/openjdk/jdk/blob/bc28baeba9360991e9b7575e1fbe178d873ccfc1/src/java.base/share/classes/jdk/internal/misc/Signal.java#L177-L178 > > Instead of separate Hashtable.get/remove calls we can just use value returned > by `remo

Re: RFR: 8285445: cannot open file "NUL:"

2022-04-25 Thread David M . Lloyd
On Sat, 23 Apr 2022 15:24:13 GMT, Alan Bateman wrote: > > FWIW we fixed the same problem by simply using `NUL` instead of `NUL:`. > > Hopefully newer code can use OutputStream.nullOutputStream(). It's portable > and avoids depending on these legacy Windows specific reserved names. One possible

Re: RFR: 8285445: cannot open file "NUL:"

2022-04-23 Thread David M . Lloyd
On Sat, 23 Apr 2022 01:11:56 GMT, Brian Burkhalter wrote: > Change the default value of the `jdk.io.File.enableADS` property to `true`. FWIW we fixed the same problem by simply using `NUL` instead of `NUL:`. - PR: https://git.openjdk.java.net/jdk/pull/8373

Re: RFR 9: 8165641 : Deprecate Object.finalize

2017-03-13 Thread David M. Lloyd
In regards to the optimized-out "this" stuff - remember that a while ago Paul Sandoz introduced java.lang.ref.Reference#reachabilityFence()... On 03/12/2017 06:55 PM, Hans Boehm wrote: I agree that's indeed a solvable problem, perhaps not terribly elegantly, but without too much user-visible co

Re: NPE on "return" bytecode of java.net.NetworkInterface

2016-11-14 Thread David M. Lloyd
On 11/14/2016 11:07 AM, David M. Lloyd wrote: On 11/14/2016 11:02 AM, David M. Lloyd wrote: On 11/14/2016 09:54 AM, David M. Lloyd wrote: On 11/14/2016 09:39 AM, Chris Hegarty wrote: On 14/11/16 15:29, Andrew Haley wrote: On 14/11/16 14:47, David M. Lloyd wrote: Since this method is

Re: NPE on "return" bytecode of java.net.NetworkInterface

2016-11-14 Thread David M. Lloyd
On 11/14/2016 11:02 AM, David M. Lloyd wrote: On 11/14/2016 09:54 AM, David M. Lloyd wrote: On 11/14/2016 09:39 AM, Chris Hegarty wrote: On 14/11/16 15:29, Andrew Haley wrote: On 14/11/16 14:47, David M. Lloyd wrote: Since this method is called from a native method, is it possible that

Re: NPE on "return" bytecode of java.net.NetworkInterface

2016-11-14 Thread David M. Lloyd
On 11/14/2016 09:54 AM, David M. Lloyd wrote: On 11/14/2016 09:39 AM, Chris Hegarty wrote: On 14/11/16 15:29, Andrew Haley wrote: On 14/11/16 14:47, David M. Lloyd wrote: Since this method is called from a native method, is it possible that somehow the native method is generating an NPE

Re: NPE on "return" bytecode of java.net.NetworkInterface

2016-11-14 Thread David M. Lloyd
On 11/14/2016 09:39 AM, Chris Hegarty wrote: On 14/11/16 15:29, Andrew Haley wrote: On 14/11/16 14:47, David M. Lloyd wrote: Since this method is called from a native method, is it possible that somehow the native method is generating an NPE, but the Java method is still in the stack context

Re: NPE on "return" bytecode of java.net.NetworkInterface

2016-11-14 Thread David M. Lloyd
On 11/14/2016 09:29 AM, Langer, Christoph wrote: Hi David, can this be reproduced? It's part of the test suite of our application server, so, probably, but probably not easily. What platform is it about? There have been fixes for some Windows native coding lately: http://hg.openjdk.java.n

Re: NPE on "return" bytecode of java.net.NetworkInterface

2016-11-14 Thread David M. Lloyd
On 11/14/2016 09:29 AM, Andrew Haley wrote: On 14/11/16 14:47, David M. Lloyd wrote: Since this method is called from a native method, is it possible that somehow the native method is generating an NPE, but the Java method is still in the stack context? I assume that what is happening here is

NPE on "return" bytecode of java.net.NetworkInterface

2016-11-14 Thread David M. Lloyd
I'm trying to work out something a colleague has observed during testing on an OpenJDK based on 1.8.0_111 (build 1.8.0_111-b16). The business end of the stack trace looks like this: Caused by: java.lang.NullPointerException at java.net.NetworkInterface.(NetworkInterface.java:80)

Re: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError

2016-11-11 Thread David M. Lloyd
On 11/11/2016 05:07 AM, Alan Bateman wrote: On 11/11/2016 10:46, Vladimir Ivanov wrote: Alan, I've looked through the current thread and also review thread [1] for original change (8165793), but haven't found any discussion why making it static (instead of instance final) is undesirable. Can

Re: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError

2016-11-10 Thread David M. Lloyd
My original suggestion for the method was to make it static, and possibly even caller-sensitive, for just this reason. On 11/09/2016 04:53 PM, Brent Christian wrote: Hi, It seems that the method name used in 8165793[1], "isParallelCapable", was a little *too* intuitive. An existing use of tha

Re: Proposal for adding O_DIRECT support into JDK 9

2016-11-04 Thread David M. Lloyd
I still feel like it could be a problem to have just one simple getPageSize method, given how many CPU architectures and OSes support multiple page sizes. On 11/04/2016 11:58 AM, Paul Sandoz wrote: Hi Lucy, I am struggling to find an entirely satisfactory location to place a method such as g

Re: Proposal for adding O_DIRECT support into JDK 9

2016-11-03 Thread David M. Lloyd
What happens if you're using large pages? Are the direct buffers always allocated off of small pages? On 11/02/2016 06:34 PM, Lu, Yingqi wrote: Hi All, Our most recent DirectIO patch is available at http://cr.openjdk.java.net/~igraves/8164900-3/ In this version, we made following changes:

Another ProcessBuilder enhancement: execve

2016-10-21 Thread David M. Lloyd
It would be useful for processes which self-update or otherwise self-manage to be able to exec a new process which replaces the current one, in the manner of POSIX execve. This might tie in with ProcessBuilder, though there are a few key differences: 1. The method to execute the process (obvi

Re: RFR 9: 8164908: ReflectionFactory support for IIOP and custom serialization

2016-10-20 Thread David M. Lloyd
On 10/19/2016 02:59 PM, Roger Riggs wrote: The support in sun.reflect.ReflectionFactory for custom serialization, such as IIOP input and output streams, is being expanded beyond the necessary constructor of a serializable class to include access to the private methods readObject, writeObject, rea

Re: Deprecate all java.util.concurrent.*FieldUpdater

2016-10-05 Thread David M. Lloyd
I'm sure I recall an email from the past few months which proposed that *FieldUpdater are still going to be recommended in many cases over VarHandle because the latter is probably too low-level for casual uses. It was (IIRC) an argument in favor of more advanced fence methods or something like

Re: RFC: System.console().encoding()

2016-09-15 Thread David M. Lloyd
On 09/15/2016 02:06 AM, Xueming Shen wrote: -1 :-) Console is supposed to be a "char/String" based class, "encoding" really should have no business here in its api. Simply for some implementation convenience is really not a good reason to add such a public method. Let's look at the two likely

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

2016-04-01 Thread David M. Lloyd
Without a resolution to https://bugs.openjdk.java.net/browse/JDK-8008240 (atomics for buffers) or https://bugs.openjdk.java.net/browse/JDK-6476827 (memory consistency properties of buffers), how meaningful is this? On 03/31/2016 07:06 PM, Hans Boehm wrote: The expectation would be that such m

Re: JAXP default implementation and JDK-8152063

2016-03-29 Thread David M. Lloyd
Peter On 03/28/2016 01:42 PM, David M. Lloyd wrote: The reason is because we use a single boot path but we don't know at the time of boot whether or not we will have a JAXP provider, nor where it will come from; that is up to the server configuration that we end up running. With the system pr

Re: JAXP default implementation and JDK-8152063

2016-03-28 Thread David M. Lloyd
ookup process to try locating a provider through the Layer of the caller if TCCL fails. I think the assumption in the previous discussion was that a new method would be introduced to take a Layer as an argument. -Joe On 3/24/2016 3:36 PM, David M. Lloyd wrote: This is all for the case where the user i

Re: JAXP default implementation and JDK-8152063

2016-03-28 Thread David M. Lloyd
hese APIs, then AFAICT it will fail with Jigsaw because we can't access the JDK's default implementations". So the question is, why did you have to override the JAXP process for the services that you don't have an AppServer-level provider ( "overriding implementation(s)"

Re: JAXP default implementation and JDK-8152063

2016-03-25 Thread David M. Lloyd
fails. I think the assumption in the previous discussion was that a new method would be introduced to take a Layer as an argument. -Joe On 3/24/2016 3:36 PM, David M. Lloyd wrote: This is all for the case where the user is calling e.g. javax.xml.stream.XMLInputFactory#newFactory() with no

Re: JAXP default implementation and JDK-8152063

2016-03-24 Thread David M. Lloyd
adapt to the new API. Would you expect that would happen or would you still have existing applications that can not be updated? -Joe On 3/24/2016 2:02 PM, David M. Lloyd wrote: On 03/24/2016 03:54 PM, huizhe wang wrote: In this discussion so far, a) I see that you seemed to have successfully use

Re: JAXP default implementation and JDK-8152063

2016-03-24 Thread David M. Lloyd
On 03/24/2016 03:54 PM, huizhe wang wrote: In this discussion so far, a) I see that you seemed to have successfully used the method with a class loader as Daniel suggested. I assume that solved the issue reported in JDK-8152063. Am I right, that you no longer have issue with using a proxy? Or

Re: JAXP default implementation and JDK-8152063

2016-03-24 Thread David M. Lloyd
On 03/24/2016 11:26 AM, Alan Bateman wrote: On 24/03/2016 16:09, David M. Lloyd wrote: : If the Layer of the module of the class calling the newInstance/newFactory/etc. method could somehow be consulted in service resolution decisions, that would definitely solve the problem because our

Re: JAXP default implementation and JDK-8152063

2016-03-24 Thread David M. Lloyd
On 03/22/2016 08:59 AM, Daniel Fuchs wrote: Would adding a method that resolves the concrete service implementation against a Layer supplied by the caller be of any help in your scenario? I think I misunderstood this when you asked it. You mean let the Layer have a hand in looking up the serv

Re: JAXP default implementation and JDK-8152063

2016-03-24 Thread David M. Lloyd
On 03/24/2016 09:51 AM, Alan Bateman wrote: On 24/03/2016 14:29, David M. Lloyd wrote: Daniel, I have hacked together a way to use the system class loader (which should be "good enough", I hope), but there is one further problem: org.xml.sax.helpers.XMLReaderFactory does not have

Re: JAXP default implementation and JDK-8152063

2016-03-24 Thread David M. Lloyd
On 03/23/2016 07:12 AM, David M. Lloyd wrote: On 03/22/2016 08:59 AM, Daniel Fuchs wrote: Hi David, On 22/03/16 13:53, David M. Lloyd wrote: Am I understanding it correctly that you're pointing the system property to a "proxy" as stated in JDK-8152063, not an actual implemen

Re: JAXP default implementation and JDK-8152063

2016-03-23 Thread David M. Lloyd
On 03/22/2016 08:59 AM, Daniel Fuchs wrote: Hi David, On 22/03/16 13:53, David M. Lloyd wrote: Am I understanding it correctly that you're pointing the system property to a "proxy" as stated in JDK-8152063, not an actual implementation? So it's sort of a provider-locating

Re: JAXP default implementation and JDK-8152063

2016-03-22 Thread David M. Lloyd
On 03/21/2016 07:42 PM, huizhe wang wrote: On 3/21/2016 12:55 PM, David M. Lloyd wrote: On 03/21/2016 01:38 PM, Alan Bateman wrote: On 21/03/2016 14:39, David M. Lloyd wrote: This message is in reference to the aforementioned issue [1] that I've requested my colleague Andrew Hughes to op

Re: JAXP default implementation and JDK-8152063

2016-03-21 Thread David M. Lloyd
On 03/21/2016 01:38 PM, Alan Bateman wrote: On 21/03/2016 14:39, David M. Lloyd wrote: This message is in reference to the aforementioned issue [1] that I've requested my colleague Andrew Hughes to open on my behalf. As expressed in that issue, the means of specifying a JAXP default pro

JAXP default implementation and JDK-8152063

2016-03-21 Thread David M. Lloyd
This message is in reference to the aforementioned issue [1] that I've requested my colleague Andrew Hughes to open on my behalf. As expressed in that issue, the means of specifying a JAXP default provider (via system property which specifies a class name on the application class path) is rela

Re: Multi-Release JAR file patch as applied to build 108 of Java 9 breaks almost every project out there (Apache Ant, Gradle, partly Apache Maven)

2016-03-07 Thread David M. Lloyd
On 03/07/2016 03:43 AM, Paul Sandoz wrote: Hi Uwe, Alan, Uwe, thanks so much for testing and investigating, that is very helpful and really appreciated. The EA process is working as intended, although i wish the result was not so debilitating in this case. Sorry about that. [...] Here is a pos

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

2016-02-22 Thread David M. Lloyd
On 02/22/2016 12:11 PM, mark.reinh...@oracle.com wrote: 2016/1/28 9:25 -0800, g...@azul.com: This thread seems to have "hopped away" to the concurrency-interest list in mid-Dec-2015. This posting is intended to capture a summary of reasoning and some of the discussion there so that we have it in

Re: DeserializationPermission Proposal

2016-02-12 Thread David M. Lloyd
Things are getting confused (for me anyway) so I'm going to try and spell out each idea separately. Given a class hierarchy H of: C -> B -> A -> NonSerializableClass -> Object where C, B, and A are serializable classes, and protection domain M which is initiating deserialization, I think the

Re: DeserializationPermission Proposal

2016-02-11 Thread David M. Lloyd
On 02/11/2016 03:52 AM, Peter Firmstone wrote: An example might be more useful. Traditionally, when the first non serializable superclass zero argument constructor is called, the domains of the subclasses aren't present on the call stack. Any security checks performed in the constructor of the

Re: DeserializationPermission Proposal

2016-02-09 Thread David M. Lloyd
On 02/08/2016 10:19 PM, Peter Firmstone wrote: Why not, just prior to instantiating an object just prior to deserializing, add each class' ProtectionDomain in the objects hierarchy to an AccessControlContext and pass this to the SecurityManager's two argument checkPermission call? This permis

Re: API review of VarHandles

2016-01-22 Thread David M. Lloyd
On 01/22/2016 07:57 AM, Aleksey Shipilev wrote: On 01/22/2016 04:54 PM, David M. Lloyd wrote: The costs are both performance and memory overhead. The Atomic*FieldUpdaters are good for memory usage and reasonably usable, but suffer from performance problems and generics issues. Hopefully, not

Re: API review of VarHandles

2016-01-22 Thread David M. Lloyd
o better. On Fri, Jan 22, 2016 at 8:34 AM, David M. Lloyd wrote: On 01/22/2016 07:29 AM, Vitaly Davidovich wrote: Experts need control more than anything else. This is not to say they'll be happy with a subpar API but control typically means lots of details so there's a limit on

Re: API review of VarHandles

2016-01-22 Thread David M. Lloyd
On 01/22/2016 07:29 AM, Vitaly Davidovich wrote: Experts need control more than anything else. This is not to say they'll be happy with a subpar API but control typically means lots of details so there's a limit on how abstracted the API can be. As mentioned, given the API provides low level co

Re: API review of VarHandles

2016-01-22 Thread David M. Lloyd
On 01/21/2016 07:32 PM, Brian Goetz wrote: I am baffled as to how the original language syntax proposal of using some trick like "xx.volatile.imaginaryMethod()" plus maybe one or two new bytecodes was considered unacceptable; looking at this API, I know that none of the aforementioned metrics w

Re: API review of VarHandles

2016-01-21 Thread David M. Lloyd
On 01/21/2016 04:42 PM, Paul Sandoz wrote: Hi This is a request to review the VarHandles API. The code reviews and pushes will occur separately, and flow through the hs-comp repo, most likely from the bottom up first with Unsafe changes. The specdiff can be found here: http://cr.openjdk.

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

2015-12-08 Thread David M. Lloyd
On 12/08/2015 07:41 AM, Peter Levart wrote: (once again, for the list - I can't seem to hit the right button :-) On 12/08/2015 01:51 PM, David M. Lloyd wrote: Yeah I think that replacing finalize is a bad example. With Reference.reachabilityFence() around the corner, if you want finaliz

Re: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals

2015-12-08 Thread David M. Lloyd
Or perhaps a builder... On 12/08/2015 08:33 AM, Roger Riggs wrote: Hi Chris, Supporting the use case in Thread is a good addition. Adding an argument to the most flexible constructor of Thread bulks up an already heavy weight constructor. Look at the cases being replaced, none of them use all

Re: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals

2015-12-08 Thread David M. Lloyd
Great! Now all we need is a way to tell threads to remove all thread locals on exit, and the scourge of ITL might be somewhat mitigated. :-) On 12/08/2015 08:15 AM, Chris Hegarty wrote: Many threads created by the platform are short lived and perform some simple async operation on behalf of the

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

2015-12-08 Thread David M. Lloyd
Yeah I think that replacing finalize is a bad example. With Reference.reachabilityFence() around the corner, if you want finalize you can (and should, I guess) just use finalize. IMO Cleaners are better when you do not want the instance of an object to be accessible at all before you clean it

Re: Code Review for JEP 259: Stack-Walking API

2015-11-16 Thread David M. Lloyd
On 11/16/2015 06:13 PM, Mandy Chung wrote: I’d like to get the code review done by this week. I renamed the static factory method from create to getInstance since “create” implies to create a new instance but the method returns a cached instance instead. I also changed the spec of getCallerCl

Re: Proposed API for JEP 259: Stack-Walking API

2015-11-14 Thread David M. Lloyd
On 11/13/2015 06:07 PM, Brian Goetz wrote: I considered Optional>. I believe it is rare to have a JNI attached thread calling StackWalker::getCallerClass from native. Most common cases will find a caller class. Returning an Optional will force most common uses to handle the case if it’s absent

Re: Code Review for JEP 259: Stack-Walking API

2015-11-12 Thread David M. Lloyd
One other kind of stack metadata that is missing (yet is present with external tools such as jstack etc.) is ancillary data about stack frames indicating whether the frame holds or is waiting on a lock. I'm not sure whether it's practical to add all this stuff though, performance-wise, unless

Re: Proposed API for JEP 259: Stack-Walking API

2015-11-05 Thread David M. Lloyd
On 11/04/2015 07:15 PM, Mandy Chung wrote: [...] For short-circuiting, I also think it’s reasonable to expect the user know how many remaining frames it expects to traverse and it may not need to increase the batch size i.e. it might not need to update the remainingNeeded over time. The user

Re: Proposed API for JEP 259: Stack-Walking API

2015-11-03 Thread David M. Lloyd
On 11/03/2015 03:33 PM, Mandy Chung wrote: On Nov 3, 2015, at 4:45 AM, Peter Levart wrote: Hi Mandy, Great API. One thing I noticed is method StackWalker.getCallerClass() which is described as equivalent to the following: walk((s) -> s.map(StackFrame::getDeclaringClass)

Re: Proposed API for JEP 259: Stack-Walking API

2015-11-02 Thread David M. Lloyd
I also agree - when an object type "passes through" a method, it's usually best to use an invariant type variable. On 11/02/2015 06:44 AM, Paul Sandoz wrote: I agree with Maurizio, the first signature is good enough. One could argue that it might be better to apply PECS since it would encourag

Re: Proposed API for JEP 259: Stack-Walking API

2015-11-02 Thread David M. Lloyd
On 10/30/2015 11:24 PM, Mandy Chung wrote: On Oct 30, 2015, at 3:38 PM, David M. Lloyd wrote: (that's what I was looking for before), or maybe even ToIntFunction where X is something that might inform the next batch size based on the work that has already been done - maybe even a Stream

Re: Proposed API for JEP 259: Stack-Walking API

2015-10-30 Thread David M. Lloyd
On 10/30/2015 03:39 PM, Mandy Chung wrote: On Oct 30, 2015, at 12:59 PM, David M. Lloyd wrote: Since this is very likely to be a one-implementation API, is there a reason to have a separate WalkerOption interface and Option enum? Seems like you could just skip the interface. Locals and

Re: Proposed API for JEP 259: Stack-Walking API

2015-10-30 Thread David M. Lloyd
On 10/30/2015 02:04 PM, Mandy Chung wrote: JEP 259: http://openjdk.java.net/jeps/259 Javadoc for the proposed StackWalker API: http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html A simple way to walk the stack: StackWalker walker = new StackWalker(StackWalke

Re: Proposed API for JEP 259: Stack-Walking API

2015-10-30 Thread David M. Lloyd
On 10/30/2015 03:26 PM, Remi Forax wrote: The batchSizeMapper should probably be something better than a Function, no? All that boxing seems unnecessary... the next best candidate I can see though is IntToLongFunction. I wonder why we didn't do an IntToIntFunction in JSR 335. Or maybe the stre

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

2015-10-27 Thread David M. Lloyd
FWIW I agree - it's just weird to have the behavior change after the fact like that. On 10/26/2015 11:37 PM, Xueming Shen wrote: Hi Steve, I know I stared to sound like a broken record :-) But I would like to suggest the team one more time to reconsider the current decision of using the "set"

Re: Spin Loop Hint support: Draft JEP proposal

2015-10-08 Thread David M. Lloyd
On 10/08/2015 05:58 AM, Doug Lea wrote: On 10/06/2015 09:28 PM, Gil Tene wrote: As for fitting in with larger-picture or theme things (listed above). I think that agonizing over the choice of where to put this is important To avoid the kinds of problems we later saw when basic JVM methods wer

Re: JEP 264: Platform Logging API and Service

2015-09-18 Thread David M. Lloyd
On 09/18/2015 11:17 AM, mark.reinh...@oracle.com wrote: New JEP Candidate: http://openjdk.java.net/jeps/264 +1 good idea! -- - DML

Re: RFR: 8132541 : (process) ProcessBuilder support for redirection to discard output

2015-09-11 Thread David M. Lloyd
Nifty, thanks! On 09/11/2015 10:30 AM, Roger Riggs wrote: Please review a proposed [1] ProcessBuilder addition to define a Redirect that will discard output. The implementation is to redirect output to /dev/null or NUL on Windows. Please review and comment if there are any unexpected side effec

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

2015-09-10 Thread David M. Lloyd
Or, the Java methods which wrap this access can just catch NPE and throw the new exception type. On 09/10/2015 09:35 AM, Vitaly Davidovich wrote: Well, you'd probably want something other than NPE here -- perhaps a new dedicated exception to signal this condition. And this means the segfault h

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

2015-09-10 Thread David M. Lloyd
On 09/10/2015 08:22 AM, Andrew Haley wrote: On 09/10/2015 12:25 PM, Vitaly Davidovich wrote: The safepoint happiness is unfortunately a separate issue in Hotspot, and it's definitely not happy times :). Part of the problem is the piggybacking of various operations on a safepoint - the safepoin

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

2015-09-09 Thread David M. Lloyd
r GC to do its thing. Perhaps such an implementation could suffice until such time that a specialized HotSpot-based solution (like what Andrew described) or other better option could be achieved. On 09/09/2015 07:41 AM, David M. Lloyd wrote: If you have access to a Windows development envir

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

2015-09-09 Thread David M. Lloyd
On 09/09/2015 08:17 AM, Andrew Haley wrote: On 09/09/2015 02:13 PM, David M. Lloyd wrote: How would you hook into the safepoint to perform the unmapping? You'd have to wait for all threads to arrive at safepoints, wouldn't you? Yes. That happens in the VM already, e.g. when

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

2015-09-09 Thread David M. Lloyd
On 09/09/2015 08:06 AM, Andrew Haley wrote: On 09/09/2015 01:58 PM, David M. Lloyd wrote: On 09/09/2015 07:49 AM, Andrew Haley wrote: On 09/09/2015 01:41 PM, David M. Lloyd wrote: If the answer to both of these can be shown to be affirmative, then I think there is a real viable solution which

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

2015-09-09 Thread David M. Lloyd
On 09/09/2015 07:49 AM, Andrew Haley wrote: On 09/09/2015 01:41 PM, David M. Lloyd wrote: If the answer to both of these can be shown to be affirmative, then I think there is a real viable solution which allows immediate release of backing resources, with the address space being reclaimed by GC

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

2015-09-09 Thread David M. Lloyd
If you have access to a Windows development environment, it seems to me that you could help directly with the testing required to determine a solution. I think my proposed remapping approach will work, but it is contingent on testing the following on Windows: * Determine if it is possible to

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

2015-09-08 Thread David M. Lloyd
On 09/08/2015 01:37 PM, Andrew Haley wrote: On 09/08/2015 06:54 PM, David M. Lloyd wrote: I think the only questionable platform at this point is Windows (to me at least, given that I do not have much experience on it). That's right, and it's Windows which has the worst problem: o

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

2015-09-08 Thread David M. Lloyd
On 09/08/2015 12:40 PM, Andrew Haley wrote: On 09/08/2015 06:03 PM, David M. Lloyd wrote: On 09/08/2015 08:11 AM, Andrew Haley wrote: On 09/08/2015 12:37 PM, David M. Lloyd wrote: Then you do the real unmap when the buffer is GC'd (maybe via Cleaner). This is very akin to how

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

2015-09-08 Thread David M. Lloyd
On 09/08/2015 08:11 AM, Andrew Haley wrote: On 09/08/2015 12:37 PM, David M. Lloyd wrote: Then you do the real unmap when the buffer is GC'd (maybe via Cleaner). This is very akin to how file descriptors are cleaned up, AFAICT. Indeed it is, and it's no better than the status quo

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

2015-09-08 Thread David M. Lloyd
On 09/08/2015 08:03 AM, Mike Hearn wrote: If you're already doing this, why not skip the level of indirection and mprotect the entire mapped region to PROT_NONE when the user unmaps? ... Then you do the real unmap when the buffer is GC'd (maybe via Cleaner). Because the reas

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

2015-09-08 Thread David M. Lloyd
On 09/08/2015 04:30 AM, Andrew Haley wrote: On 09/08/2015 09:58 AM, Paul Sandoz wrote: This is fundamentally about *integrity* of the runtime. It follows there are security implications, but it’s still fundamentally an integrity issue and guarding an unsafe operation with a Security Manager is

One more minor addition to ProcessBuilder

2015-07-27 Thread David M. Lloyd
Roger & co.: Since you're already on the topic of manipulating pipes, I thought I'd mention one very small yet very useful potential enhancement. It would be very handy to be able to specify a NULL/bit-bucket source/destination for pipes. For the target process' input, the user can generall

Re: Why isn't Object.notify() a synchronized method?

2015-05-28 Thread David M. Lloyd
Since most of the time you have to hold the lock anyway for other reasons, I think this would generally be an unwelcome change since I expect the cost of recursive lock acquisition is nonzero. On 05/28/2015 11:08 AM, Ulf Zibis wrote: Hi all, in the Javadoc of notify(), notifyAll() and wait(..

Re: RFR [9] Add blocking bulk read to java.io.InputStream

2015-04-23 Thread David M. Lloyd
I believe this is similar to how InterruptedIOException works, FWIW. On 04/23/2015 09:20 AM, Peter Levart wrote: Hi Chris, Currently InputStream guarantees that either some bytes are read *xor* EOF (-1) is returned *xor* IOException is thrown. Even with default implementation of read(byte[], in

Re: RFR 9: 8077350 Process API Updates Implementation Review

2015-04-17 Thread David M. Lloyd
On 04/17/2015 11:53 AM, Roger Riggs wrote: Hi Peter, On 4/17/2015 4:05 AM, Peter Levart wrote: Hi Roger, Retrieving and caching the process start time as soon as ProcessHandle is instantiated might be a good idea. "destroy" native code would then use pid *and* start time to check the identity

Re: RFR [9] 8071472: Add field setter API for setting final fields in readObject

2015-03-25 Thread David M. Lloyd
On 03/25/2015 04:58 PM, Chris Hegarty wrote: On 25 Mar 2015, at 17:32, Peter Levart wrote: On 03/25/2015 05:55 PM, Peter Levart wrote: On 03/25/2015 04:49 PM, Chris Hegarty wrote: I have been thinking about this and I see several solutions: 1. provide protected final methods ObjectInputStr

Re: Fw: Re: RFR [9] 8071472: Add field access to support, setting final fields in readObject

2015-03-25 Thread David M. Lloyd
the stream, a StreamCorruptedException will > > > occur when an earlier class implementation reads it. > > > > > > For that reason, I'd reccommend against including it in the spec. > > > > > > Regards, > > > > > > Peter. > >

Re: Fw: Re: RFR [9] 8071472: Add field access to support, setting final fields in readObject

2015-03-21 Thread David M. Lloyd
3/20/2015 09:31 AM, Peter Levart wrote: On 03/20/2015 02:03 PM, David M. Lloyd wrote: private static void altReadObject(ObjectInputStream in, FieldAccess fieldAccess) throws IOException, ClassNotFoundException { // the same as in readObject, but doesn't have direct acce

Re: Fw: Re: RFR [9] 8071472: Add field access to support setting final fields in readObject

2015-03-20 Thread David M. Lloyd
On 03/20/2015 09:31 AM, Peter Levart wrote: On 03/20/2015 02:03 PM, David M. Lloyd wrote: private static void altReadObject(ObjectInputStream in, FieldAccess fieldAccess) throws IOException, ClassNotFoundException { // the same as in readObject, but doesn't have direct acce

Re: Fw: Re: RFR [9] 8071472: Add field access to support setting final fields in readObject

2015-03-20 Thread David M. Lloyd
On 03/20/2015 05:49 AM, Peter Firmstone wrote: - Original message - From Peter Levart Sent Fri, 20 Mar 2015, 01:21:17 EST To Peter Firmstone , core-libs-dev@openjdk.java.net Subject Re: RFR [9] 8071472: Add field access to support setting final fields in readObject On 03/19/2015 11

Re: JEP 238: Multi-Version JAR Files

2015-02-27 Thread David M. Lloyd
On 02/27/2015 07:27 AM, Florian Weimer wrote: On 02/12/2015 09:52 PM, Paul Sandoz wrote: Hi In connection with the JEP there is also a design document to help the discussion: http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md We are especially interesting in hearing

Re: JEP 238: Multi-Version JAR Files

2015-02-25 Thread David M. Lloyd
On 02/25/2015 11:41 AM, Paul Sandoz wrote: On Feb 25, 2015, at 5:27 PM, Brian Goetz wrote: On 2/12/2015 5:59 PM, Stephen Colebourne wrote: Interesting direction. Reading carefully, the goal is actually very limited in scope, by preventing any public API changes. It doesn't help adoption o

Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses

2015-02-18 Thread David M. Lloyd
It's an awful lot of pain to avoid what IMO should be an obvious addition: (Short|Character|Integer|Long).(get|put)(Little|Big)EndianBytes([value,] byte[] b, int offs) This could (it seems to me) be easily intrinsified, is hugely useful both within and outside of the JDK, and fits perfectly w

Re: JEP 102 Process Updates revised API draft

2015-02-13 Thread David M. Lloyd
On 02/13/2015 09:15 AM, Peter Levart wrote: On 02/13/2015 03:22 PM, Paul Sandoz wrote: >It*is* inconvenient for the user to have to use wildcards in specifying types: > >CompletableFuture cf = process.completableFuture(); > >...but it doesn't hinder the use of above 'cf' quite so much as 'len'

Re: JEP 102 Process Updates revised API draft

2015-02-10 Thread David M. Lloyd
On 02/09/2015 07:52 PM, Roger Riggs wrote: On 2/9/15 6:44 PM, David M. Lloyd wrote: Also, as a general comment, there isn't really a good explanation as to what the difference is between a normal destroy and a forcible destroy. Given that you've added an isDestroyForcible() method,

Re: JEP 102 Process Updates revised API draft

2015-02-09 Thread David M. Lloyd
On 02/09/2015 05:25 PM, Roger Riggs wrote: Hi, After a protracted absence from working on JEP 102, the updated API draft provides access to process hierarchies and individual process information; as permitted by the OS. The relationship between Process and ProcessHandle is clarified and the secu

Re: Explicit Serialization API and Security

2015-01-21 Thread David M. Lloyd
At some point, the responsibility *must* fall on the author of the serializable class in question to avoid constructs which are exploitable - like finalizers, and classes that can have side-effects before validation can be completed. On 01/21/2015 02:26 PM, Peter Firmstone wrote: Don't forget

Re: Explicit Serialization API and Security

2015-01-12 Thread David M. Lloyd
On 01/12/2015 05:51 AM, Chris Hegarty wrote: On 08/01/15 22:03, David M. Lloyd wrote: private static void validate(GetField fields) { if (fields.getInt("lo") > fields.getInt("hi")) { ... } } ... In fact you cannot validate invariants

Re: Explicit Serialization API and Security

2015-01-08 Thread David M. Lloyd
On 01/08/2015 02:10 PM, Brian Goetz wrote: 1) Validate invariants A clear and easy to understand mechanism that can validate the deserialized fields. Does not prevent the use of final fields, as the serialization framework will be responsible for setting them. Something along the

Re: Explicit Serialization API and Security

2015-01-08 Thread David M. Lloyd
On 01/08/2015 02:32 AM, Peter Firmstone wrote: Thank you all for participating in this discussion. Initially a constructor signature for deserialization was proposed to enforce invariants and encapsulation, however there appears to be interest in using alternative methods, although they appear t

Re: Explicit Serialization API and Security

2015-01-07 Thread David M. Lloyd
On 01/07/2015 10:02 AM, Peter Levart wrote: On 01/07/2015 03:54 PM, Chris Hegarty wrote: On 06/01/15 17:49, Peter Levart wrote: On 01/06/2015 06:21 PM, Chris Hegarty wrote: On 6 Jan 2015, at 15:06, Peter Levart wrote: On 01/06/2015 04:03 PM, Peter Levart wrote: private void readObject(Obje

Re: Explicit Serialization API and Security

2015-01-05 Thread David M. Lloyd
On 01/03/2015 02:29 PM, Peter Firmstone wrote: - Original message - Wouldn't it be better to "register" for finalization just those instances that complete their construction or deserialization normally? I'm just trying to understand why it is the way it is. Perhaps that might be an o

Re: Explicit Serialization API and Security

2015-01-05 Thread David M. Lloyd
On 01/03/2015 09:36 AM, Peter Levart wrote: On 01/03/2015 01:38 PM, Peter Firmstone wrote: > Hi, > > I would like to know what are the potential issues with simple > constructor chaining where each constructor checks the invariant of its > class state (with the already initialized state of sup

Re: RFR JDK-8066867: Add InputStream transferTo to transfer content to an OutputStream

2014-12-09 Thread David M. Lloyd
On 12/09/2014 09:47 AM, Pavel Rappo wrote: Hi everyone, Could you please review my change for JDK-8066867? http://cr.openjdk.java.net/~prappo/8066867/webrev.00/ In the NIO version of this method, it accepts a 'long' parameter which indicates how many bytes should be transferred (similar to s

Re: Should some JDK system properties be read only ?

2014-12-04 Thread David M. Lloyd
On 12/04/2014 10:21 AM, Seán Coffey wrote: On 04/12/2014 16:00, David M. Lloyd wrote: On 12/04/2014 09:42 AM, Seán Coffey wrote: Apologies if this has been raised in past. I've run into issues in the past where bad user code (app server) has set the java.home system property to a value

Re: Should some JDK system properties be read only ?

2014-12-04 Thread David M. Lloyd
On 12/04/2014 09:42 AM, Seán Coffey wrote: Apologies if this has been raised in past. I've run into issues in the past where bad user code (app server) has set the java.home system property to a value other than the default. This has consequences for apps/code that depend heavily on java.home ret

  1   2   3   >