I think this work (which is good) underlines a general there for some
kind of pluggable logic for converting a synthetic method name into
something more useful for the reader and/or to manipulate stack trace
elements (i.e. remove elements, fold 2-3 elements into a new one, etc.).
Lambda methods
Hi Roger,
Thanks. I’ll proceed with a CCC request then which I assume will be needed.
Brian
On Feb 17, 2015, at 3:05 PM, Roger Riggs wrote:
> Hi Brian,
>
> Makes sense to me; simple, direct and easy to explain.
>
> Roger
>
> On 2/17/2015 4:56 PM, Brian Burkhalter wrote:
>> http://mail.ope
On 02/17/2015 07:54 AM, John Rose wrote:
On Feb 16, 2015, at 10:33 PM, Staffan Larsen wrote:
The first shot at fixing this bug was to filter out ACC_SYNTHETIC. The drawback
was that the actual lambda method are marked ACC_SYNTHETIC, so that filtered
too much.
OTOH it seems odd to filter out
Hi Brian,
Makes sense to me; simple, direct and easy to explain.
Roger
On 2/17/2015 4:56 PM, Brian Burkhalter wrote:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031502.html
Begin forwarded message:
From: Brian Burkhalter
Subject: [9] RFR JDK-8068373: (prefs) FileSy
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031502.html
Begin forwarded message:
> From: Brian Burkhalter
> Subject: [9] RFR JDK-8068373: (prefs) FileSystemPreferences writes \0 to XML
> storage, causing loss of all preferences
> Date: February 12, 2015 at 1:01:43 PM PST
This change looks good - thanks.
On Tue, Feb 17, 2015 at 11:39 AM, Brian Burkhalter <
brian.burkhal...@oracle.com> wrote:
>
> On Feb 17, 2015, at 10:52 AM, Brian Burkhalter <
> brian.burkhal...@oracle.com> wrote:
>
> > Please review at your convenience.
> >
> > Issue:https://bugs.openjdk.
On Feb 17, 2015, at 10:52 AM, Brian Burkhalter
wrote:
> Please review at your convenience.
>
> Issue:https://bugs.openjdk.java.net/browse/JDK-8073347
> Patch:http://cr.openjdk.java.net/~bpb/8073347/
>
> Note the before and after versions of the HTML.
All right: round two. Pat
Hi,
Here is a new webrev - which should contain all the feedback received
so far:
#1 LogRecord uses serialPersistentFields for serialization, and
contains an Instant instead of the two fields millis +
nanoAdjustment.
#2 getMillis/setMillis are deprecated, replaced by getInstant/setInstant
IMO I don't think such barriers should be removed just because EA is able
to elide the heap allocation.
On Tue, Feb 17, 2015 at 2:15 PM, Vladimir Kozlov wrote:
> There was discussion should we remove such barriers or not because they
> create memory operations ordering which could be different i
Hi Peter, et.al.,
I have no particular issue with adding waitForUninterruptibly but it
does not
help with the lack of scalability when handling many processes.
It requires a thread to do the waiting whether from a specific caller or
a thread pool
The intent of proving a Future/CF was to allo
Thanks for the prompt response.
I think there's now an unbalanced } in the javadoc.
Although this bug report was only about Formattable, I was hoping to fix
all the scrunched-up @code's.
(@code that extends over more than 2 lines should have a added, using
the standard idiom. I've gone ahead and
On Feb 17, 2015, at 11:09 AM, Martin Buchholz wrote:
> Thanks for the prompt response.
You’re welcome.
> I think there's now an unbalanced } in the javadoc.
I’ll look.
> Although this bug report was only about Formattable, I was hoping to fix all
> the scrunched-up @code's.
> (@code that ex
There was discussion should we remove such barriers or not because they
create memory operations ordering which could be different if we remove
them.
To eliminate them we need to add 'precedent' edge to store's membar as
we do, for example, for loads:
if (field->is_volatile()) {
// Mem
What do you mean exactly? I don't think inlining "hides" anything, so the
explicit fence should still be there for EA to see (and preserve).
sent from my phone
On Feb 17, 2015 1:58 PM, "Andrew Haley" wrote:
> On 02/17/2015 06:42 PM, John Rose wrote:
> > The remaining store fence is probably a bu
On 02/17/2015 06:42 PM, John Rose wrote:
> The remaining store fence is probably a bug. A store fence for scalarized
> (lifted-out-of-memory) final fields should go away, since the fields are not
> actually stored in heap memory.
After inlining how would escape analysis know that the store fenc
Please review at your convenience.
Issue: https://bugs.openjdk.java.net/browse/JDK-8073347
Patch: http://cr.openjdk.java.net/~bpb/8073347/
Note the before and after versions of the HTML.
Thanks,
Brian
On Feb 17, 2015, at 6:22 AM, Andrew Haley wrote:
>
> Everything gets inlined nicely and the ByteBuffer is not created, but
> a store fence remains because of the final fields in HeapByteBuffer.
Wow, that got closer to the goal than I expected. In general, the EA analysis
can fail "at random" b
On 02/17/2015 07:54 AM, John Rose wrote:
On Feb 16, 2015, at 10:33 PM, Staffan Larsen wrote:
The first shot at fixing this bug was to filter out ACC_SYNTHETIC. The drawback
was that the actual lambda method are marked ACC_SYNTHETIC, so that filtered
too much.
OTOH it seems odd to filter out
Thank you for your review.
My apologies for sending an inappropriate request.
Cipher should not throw the ShortBufferException because the buffer is
enlarged before update() or doFinal(). The enlarged size is based on the
result of getOutputSize().
Even if I use the destination buffer, CipherInpu
On 02/17/2015 10:53 AM, Andrew Haley wrote:
> I see. So the question could also be whether escape analysis would
> notice that a ByteBuffer does not escape. I hope to know that soon.
Close but no cigar.
long getLong(byte[] bytes, int i) {
return ByteBuffer.wrap(bytes).getLong(i);
Am 17.02.2015 um 04:35 schrieb John Rose:
On Feb 14, 2015, at 12:01 AM, Andrew Haley wrote:
On 02/14/2015 12:09 AM, John Rose wrote:
We also need Unsafe.getIntMisaligned, etc., which wire through to whatever
second-best mechanism the platform offers.
Indeed. I'm intending to prototype a des
FWIW, when I checked, ByteBuffer.wrap(...).getXXX() type of code didn't EA
out the BB; it seems the call chain is too complex for EA. I checked 7u60
though, so maybe newer versions are different.
sent from my phone
On Feb 17, 2015 5:53 AM, "Andrew Haley" wrote:
> On 02/17/2015 10:49 AM, Florian
Am 17.02.2015 um 11:53 schrieb Andrew Haley:
On 02/17/2015 10:49 AM, Florian Weimer wrote:
That is, the byte array is supplied by the caller, and if we wanted to
use a ByteBuffer, we would have to allocate a fresh one on every
iteration. In this case, neither of the two alternatives you list a
On 02/17/2015 01:53 PM, Dai Nakanishi wrote:
> +} catch (ShortBufferException e) {
> +obuffer = null;
> +throw new IOException(e);
> }
This doesn't look right to me. You need to enlarge the buffer and retry.
If you really want to avoid allocations, you sh
Hi,
CipherInputStream and CipherOutputStream call the Cipher methods update
and doFinal which produce new byte array. It may consume a large amount
of memory.
The purpose of my patch is to avoid this. Could you review the patch?
Thanks,
Dai
--- old/src/share/classes/javax/crypto/CipherInputStre
On 02/17/2015 10:49 AM, Florian Weimer wrote:
> On 02/17/2015 11:22 AM, Andrew Haley wrote:
>>> You'll still have to allocate a wrapping ByteBuffer object to use them.
>>> I expect that makes them unattractive in many cases.
>>
>> Hmm. I'm having a hard time trying to understand why. If you need
On 02/17/2015 11:22 AM, Andrew Haley wrote:
>> You'll still have to allocate a wrapping ByteBuffer object to use them.
>> I expect that makes them unattractive in many cases.
>
> Hmm. I'm having a hard time trying to understand why. If you need to
> do a lot of accesses the allocation of the By
On 02/17/2015 10:15 AM, Florian Weimer wrote:
> On 02/17/2015 11:00 AM, Andrew Haley wrote:
>> On 02/17/2015 09:39 AM, Florian Weimer wrote:
>>> On 02/14/2015 01:09 AM, John Rose wrote:
These queries need to go into Unsafe.
We also need Unsafe.getIntMisaligned, etc., which wire through to
On 02/17/2015 11:00 AM, Andrew Haley wrote:
> On 02/17/2015 09:39 AM, Florian Weimer wrote:
>> On 02/14/2015 01:09 AM, John Rose wrote:
>>> These queries need to go into Unsafe.
>>> We also need Unsafe.getIntMisaligned, etc., which wire through to whatever
>>> second-best mechanism the platform of
On 02/17/2015 09:39 AM, Florian Weimer wrote:
> On 02/14/2015 01:09 AM, John Rose wrote:
>> These queries need to go into Unsafe.
>> We also need Unsafe.getIntMisaligned, etc., which wire through to whatever
>> second-best mechanism the platform offers.
>
> The safe variants should go into the ja
On 02/14/2015 11:10 PM, Dean Long wrote:
> Even if linux-aarch64 always allows unaligned, checking only for
> "aarch64" is not future-proof
> because it doesn't take the OS into account.
Surely a simple test case is sufficient to ensure that the platform
supports misaligned accesses? Then new po
On 02/14/2015 01:09 AM, John Rose wrote:
> These queries need to go into Unsafe.
> We also need Unsafe.getIntMisaligned, etc., which wire through to whatever
> second-best mechanism the platform offers.
The safe variants should go into the java.lang.Integer etc. classes
IMHO. Even the JDK has qu
On 16/02/2015 21:58, Brian Burkhalter wrote:
Please review at your convenience:
Issue: https://bugs.openjdk.java.net/browse/JDK-8073207
Patch: http://cr.openjdk.java.net/~bpb/8073207/webrev.00/
Simply implements what the description suggests.
Looks good, I don't know how long it has been th
33 matches
Mail list logo
