Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Roger, On 04/05/2016 04:41 PM, Peter Levart wrote: On 04/04/2016 11:50 PM, Roger Riggs wrote: I don't see the need to change Cleaner to an interface to be able to provide an additional method on CleanerImpl or a subclass and a factory method could provide for a clean and very targeted inte

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

Hello Steve, Thank you for addressing all concerns raised in the discussion. For my points: Using BufferSupplier or similar as the interface name can be mixed with class/constructor names which describe the actual type of memory. However yes I agree that “Memory” has the additional benefit tha

Re: [9] RFR JDK-8153564: Add java/nio/Buffer/BasicByte.java to exclude list until JDK-8153563 is fixed

I didn't see that one failing on my jprt sanity job I went to check the code CopyDirectMemory.java, and it doesn't use jdk.internal.misc.Unsafe (at least directly), so doesn't look like it's the same issue. where did you see the failure ? Alejandro On 4/5/2016 11:59 PM, Amy Lu wrote: java

Re: [9] RFR JDK-8153564: Add java/nio/Buffer/BasicByte.java to exclude list until JDK-8153563 is fixed

java/nio/Buffer/CopyDirectMemory.java run into the same issue, maybe it could be problem listed together in this patch? Thanks, Amy On 4/6/16 1:14 PM, Alejandro Murillo wrote: I'd like to push the changeset below to exclude java/nio/Buffer/BasicByte.java It started failing after the hotspot

Re: RFR 8153123 : Streamline StackWalker code

> On Apr 5, 2016, at 4:48 PM, Brent Christian > wrote: > > Thanks, Coleen. Coordinating method/function names on "to stack trace > element" is a fine thing. I've done so in the updated webrev, and also > implemented Claes's suggestion. > > http://cr.openjdk.java.net/~bchristi/8153123/webre

[9] RFR JDK-8153564: Add java/nio/Buffer/BasicByte.java to exclude list until JDK-8153563 is fixed

I'd like to push the changeset below to exclude java/nio/Buffer/BasicByte.java It started failing after the hotspot snapshot was pushed to jdk9/dev tonight. https://bugs.openjdk.java.net/browse/JDK-8153563 has been filed for that failure. $ hg -R jdk9.dev/jdk tip -pv changeset: 14082:5c98

Re: RFR:

+1 On 4/5/2016 11:48 PM, Kumar Srinivasan wrote: > Hi, > > The issue here was jimage extract was taking too long, exploding > the modules onto certain slow filesystems, thus causing test > timeouts. Now using jrtfs to zipfs, it takes a small fraction of > that time. > > Please review: > http://

Re: RFR: JDK-8152622: tools/pack200/Pack200Props.java timed out

Hi, I made some adjustments, based on private feedback. New Webrev: http://cr.openjdk.java.net/~ksrini/8152622/webrev.01/ Changes * Modified ModuleAttributes test to use the new utility method, this also requires a way to filter/select filename patterns. * Use preVisitDirectory to crea

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Peter, > On Apr 5, 2016, at 7:41 AM, Peter Levart wrote: > > The bottom line is that we need a mechanism that: > > - triggers reference discovery when native memory limit is approached or > reached > - retires native memory reservation at appropriate time slots until > succeeding or until

JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

Re: JDK-8153111 Hi, Below are responses to some of the points brought up in the discussion as well as is a little expansion of the reasoning that went into the proposed API. One motivation we saw for doing anything beyond a concrete ByteBuffer

Re: RFR 8153123 : Streamline StackWalker code

Thanks, Coleen. Coordinating method/function names on "to stack trace element" is a fine thing. I've done so in the updated webrev, and also implemented Claes's suggestion. http://cr.openjdk.java.net/~bchristi/8153123/webrev.01/index.html -Brent On 04/05/2016 11:25 AM, Coleen Phillimore wrot

Re: Bug id : 8140747 - Data corruption when parsing XML using StAX/Xerces

Hi Vlad, This bug was fixed in 7u80. Please, see JDK-8059327 [1] for more information. Also I have successfully executed the test from JDK-8140747 on 7u80 and on 7u75 with [1] applied: It gave me a lot of 'rugs' =). Best Regards, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8059327 O

Re: RFR [9] 8153498: Update the PostVMInitHook mechanism to use an internal package in the base module

> On Apr 5, 2016, at 2:51 AM, Chris Hegarty wrote: > > sun.misc.PostVMInitHook::run is called by the VM once its initialization is > complete, when jdk_version_info.post_vm_init_hook_enabled bit is true. > Since sun.misc will be moved out of the base module, the VM should > look for the PostVMIn

Re: RFR: JDK-8152622: tools/pack200/Pack200Props.java timed out

sorry missed the subject. Kumar Hi, The issue here was jimage extract was taking too long, exploding the modules onto certain slow filesystems, thus causing test timeouts. Now using jrtfs to zipfs, it takes a small fraction of that time. Please review: http://cr.openjdk.java.net/~ksrini/

Re: RFR 8153123 : Streamline StackWalker code

A correction below. On 4/5/16 1:29 PM, Coleen Phillimore wrote: Also meant to include core-libs-dev in the email. Thanks, Coleen On 4/5/16 1:27 PM, Coleen Phillimore wrote: Hi, I've reviewed the hotspot changes and some of the jdk changes. This looks really good. One comment about the jv

RFR:

Hi, The issue here was jimage extract was taking too long, exploding the modules onto certain slow filesystems, thus causing test timeouts. Now using jrtfs to zipfs, it takes a small fraction of that time. Please review: http://cr.openjdk.java.net/~ksrini/8152622/webrev.00/ Fix for: https:

Re: RFR 8153123 : Streamline StackWalker code

Hi, On 04/05/2016 01:45 AM, Brent Christian wrote: Hi, I'd like to check in some footprint and code reduction changes to the java.lang.StackWalker implementation. Webrev: http://cr.openjdk.java.net/~bchristi/8153123/webrev.00/ this looks really good to me. It seems the new implementation

Re: RFR 8153123 : Streamline StackWalker code

Also meant to include core-libs-dev in the email. Thanks, Coleen On 4/5/16 1:27 PM, Coleen Phillimore wrote: Hi, I've reviewed the hotspot changes and some of the jdk changes. This looks really good. One comment about the jvm function names: I think FillInStackTraceElement is too close of

Re: RFR(XXS): 8149519: Investigate implementation of java.specification.version

Hi, can somebody please review this trivial change? Regards, Volker On Mon, Apr 4, 2016 at 6:47 PM, Volker Simonis wrote: > Hi, > > can I please have a review for this small fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519 > https://bugs.openjdk.java.net/browse/JDK-8149519 > >

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

On 04/04/2016 05:45 PM, Martin Buchholz wrote: I think this one is going too far. A*FU/VarHandles should are supposed to act like a go-to replacement for Unsafe throughout the class library, and we want to shrink the Unsafe exposure. Also, I don't think removing A*FU in favor of Unsafe here wins

Re: toRealPath throws InternalError: Should not get here on Windows (paths with junctions)

Hi Dawid, I updated the bug. Rgds,Rory On 05/04/2016 11:47, Dawid Weiss wrote: I did a bit more digging. I can reproduce this every time on my machine if: 1) I open cmd from total commander (64 bit or 32 bit, doesn't matter); 2) from that cmd run the simple example in Java that attempts to re

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Roger, On 04/04/2016 11:50 PM, Roger Riggs wrote: Hi Peter, Stepping back just a bit. Right, let's clear up. The old Cleaner running on the Reference processing thread had a few (2) very well controlled functions, reference processing and deallocating DirectByteBuffers. Maybe we can'

Re: RFR [9] 8153498: Update the PostVMInitHook mechanism to use an internal package in the base module

Hotspot changes look good. Lois On 4/5/2016 5:51 AM, Chris Hegarty wrote: sun.misc.PostVMInitHook::run is called by the VM once its initialization is complete, when jdk_version_info.post_vm_init_hook_enabled bit is true. Since sun.misc will be moved out of the base module, the VM should look for

Re: toRealPath throws InternalError: Should not get here on Windows (paths with junctions)

I did a bit more digging. I can reproduce this every time on my machine if: 1) I open cmd from total commander (64 bit or 32 bit, doesn't matter); 2) from that cmd run the simple example in Java that attempts to resolve real path; this ends in InternalError. On the other hand, if I run cmd from t

RFR [9] 8153498: Update the PostVMInitHook mechanism to use an internal package in the base module

sun.misc.PostVMInitHook::run is called by the VM once its initialization is complete, when jdk_version_info.post_vm_init_hook_enabled bit is true. Since sun.misc will be moved out of the base module, the VM should look for the PostVMInitHook in a more suitable place, say jdk.internal.vm. http://cr