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: 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

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

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

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: 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:

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 >

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

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

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

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

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. > >

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: 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

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

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: >

[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:

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.

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