Hi,
Signature hashCode (the static class in MethodUtil) should be eagerly
calculated (i.e. a final field too) since the only usage is being a key in
the hashmap.
I will add bit more later.
Stanimir
On Wed, Nov 19, 2014 at 2:42 AM, Martin Buchholz marti...@google.com
wrote:
Hi Joe, Peter,
HashArray.java:
82 Integer.highestOneBit(expectedMaxSize +
(expectedMaxSize 1))
This effectively multiples expectedMaxSize by 3, I guess you meant
instead.
The intention of capacity(int expectedMaxSize) is to return the smallest
power of 2 number that is greater than 3
Hi Staffan,
Given the tables in the static class init :
66 private transient final static int[] byteTable0 = byteTables[0];
67 private transient final static int[] byteTable1 = byteTables[1];
68 private transient final static int[] byteTable2 = byteTables[2];
69 private
A very small issue:
MethodTable.java:
697 while (i hwm next == null) next = methods[i++];
In my opinion the condition should be while (next == null i hwm) as next
will be non-null on each invocation of next() and generally it's more
likely to exit the loop.
I suppose
945 } catch (Exception ex) {
946 System.err.println(Can't load log
handler \ + type + \);
947 System.err.println( + ex);
948 ex.printStackTrace();
949 }
I'm not quite sure if
Hi,
917 final boolean ensureCloseOnReset = names.length
== 0 ? false
918 : getBooleanProperty(handlersPropertyName
+ .ensureCloseOnReset,
919 names.length 0);
I think the statement would be a lot easier to read as: final
Hi,
Personally I have no objections to the latest webrev.
It looks like you are creating a more sophisticated data structure
with more garbage, which won't show up as much on our small-memory
benchmarks. Which is why I was expecting to have to write an adaptive
data structure that
Aside, I noticed in this code:
146 forkSecondaryFinalizer(new Runnable() {
147 private volatile boolean running;
148 public void run() {
149 if (running)
150 return;
151 final JavaLangAccess jla =
Hi Peter,
The removal of value wrapper is a clever approach to reduce the new
instances created although it feels very unnatural (at least to me). Small
optimization; eagerly calculate the hash in the c'tor,
hash =
149 method.getReturnType().hashCode() ^
150
On Mon, Oct 27, 2014 at 1:23 PM, Aleksey Shipilev
aleksey.shipi...@oracle.com wrote:
On 10/27/2014 01:53 AM, Peter Levart wrote:
As you might have noticed, the number of methods obtained from patched
code differed from original code. I have investigated this and found
that original code
On Mon, Oct 27, 2014 at 12:36 AM, Peter Levart peter.lev...@gmail.com
wrote:
On 10/26/2014 11:21 PM, Stanimir Simeonoff wrote:
Great effort.
From first glance: the hashCode and equals of MethodList use
m.getParameterTypes() which is cloned. I'd rather pay the collision costs
and rely
55 java/lang/reflect jtreg tests still pass. As they did before, which
means that we don't have a coverage for such cases. I'll see where I can
add such a case (EnumSet for example, which inherits from Set interface and
AbstractColection class via two different paths, so Set.size()/iterator()
UnsupportedOperationException();
}
Regards, Peter
//Staffan
On 10/22/2014 05:37 PM, Stanimir Simeonoff wrote:
Hi Staffan,
The readonly buffer (ByteBuffer.asReadOnlyBuffer()) don't have array()
working.
You can use int length = Math.min(buffer.remaining, b.length) instead,
same with new
, UNSAFE.getObject(buffer, offsetOffset)
Obviously should be Unsafe.getInt(buffer, offsetOffset)
On Thu, Oct 23, 2014 at 11:16 AM, Stanimir Simeonoff stani...@riflexo.com
wrote:
Unsafe is available, so the fields (array, offset) can be read directly
UNSAFE.getObject(buffer, hbOffset
I was under the impression the declaring order has been abandoned in 1.7
which I considered quite a let down as allowed ordering the function calls
in JMX in a non-chaotic way.
On Thu, Oct 23, 2014 at 4:37 PM, Peter Levart peter.lev...@gmail.com
wrote:
On 10/23/2014 01:57 AM, Stanimir
On Thu, Oct 23, 2014 at 12:10 AM, Bernd Eckenfels e...@zusammenkunft.net
wrote:
Hello,
just a question in the default impl:
+} else {
+byte[] b = new byte[rem];
+buffer.get(b);
+update(b, 0, b.length);
+}
would it be a good idea to
Class.java can easily be improved by adding an auxiliary HasMapString,
Integer/int[] indexing the position in the array by name and then checking
only few overloaded signatures in case of a match.
The auxiliary map can be deployed only past some threshold of methods, so
it should not affect the
);
}
Xueming, do you have any further comment?
Regards,
Staffan
On 10/22/2014 03:04 PM, Stanimir Simeonoff wrote:
On Thu, Oct 23, 2014 at 12:10 AM, Bernd Eckenfels e...@zusammenkunft.net
wrote:
Hello,
just a question in the default impl:
+} else {
+byte[] b = new byte
:
http://cr.openjdk.java.net/~plevart/jdk9-dev/ClassLoader.CNFE/webrev.02/
Regards, Peter
On 10/16/2014 09:35 AM, Peter Levart wrote:
On 10/16/2014 01:49 AM, Stanimir Simeonoff wrote:
First, really nice tests.
As for hiding: missing the real classloader impl. might be quite a
bumper
Hi,
A minor issue: there are quite a few instances of parsing integers via
Integer.valueOf(String) instead just Integer.parseInt(String):
HijrahChronology.java:
864 int year = Integer.valueOf(key);
972 months[i] = Integer.valueOf(numbers[i]);
Those
Hi,
I don't quite see the point of this line:
private transient final static ByteOrder ENDIAN
= ByteOrder.nativeOrder().equals(ByteOrder.BIG_ENDIAN)
? ByteOrder.BIG_ENDIAN : ByteOrder.LITTLE_ENDIAN;
should be just private static final ByteOrder ENDIAN =
Also, ede
Unsafe.ADDRESS_SIZE == 4
That doesn't imply 32bit systems as with less than 32GiB (on 64bit) the
default is using compressed options and the address size is still only
4bytes.
I usually use something like this (in user space code) to detect the
architecture
private static final
)
Address Size: 4
//Staffan
On 10/17/2014 12:54 PM, Stanimir Simeonoff wrote:
Also, ede
Unsafe.ADDRESS_SIZE == 4
That doesn't imply 32bit systems as with less than 32GiB (on 64bit) the
default is using compressed options and the address size is still only
4bytes.
I usually use something
First, really nice tests.
As for hiding: missing the real classloader impl. might be quite a bumper
for some middleware implementations. That would make pretty hard to trace
dependency issues without explicit logging, the latter is usually available
but still. Also it'd depend if the classloaders
Hi,
This is an unrelated issue, yet is there any reason for the inner loop of
equals to be written in such a (confusing) way?
if (n == anotherString.value.length) {
char v1[] = value;
char v2[] = anotherString.value;
int i = 0;
a
On Tue, Oct 14, 2014 at 10:55 PM, Alan Bateman alan.bate...@oracle.com
wrote:
On 14/10/2014 18:38, Aleksey Shipilev wrote:
Thanks guys!
And of course, I managed to do two minor mistakes in a two-line change:
the indentation is a bit wrong, and cast to String is redundant. Here is
the
The commented annotation in ClassLoader.java must be removed (line 268)
// @GuardedBy(itself)
Stanimir
On Fri, Oct 10, 2014 at 6:10 PM, Claes Redestad claes.redes...@oracle.com
wrote:
Hi all,
please review this patch which attempts to clean up synchronization and
improve scalability when
Hi,
LogManager.reset() should invoke a package private method to delete all
lock files. However, that would require holding the FileHandler.locks
monitor during the resetting of FileHandlers, not just the deletion
process. Something like that, plus new PrivilegedAction().
static void
-libs-dev@openjdk.java.net
Subject: Re: JDK-6774110 lock file is not deleted when child logger is
used
Hi Stanimir, Jason,
On 10/10/14 10:02, Stanimir Simeonoff wrote:
Hi,
LogManager.reset() should invoke a package private method to delete all
lock files. However, that would require
persistentLoggers should be cleared on reset(), imo.
Also using count and then for in to loop over an array looks a bit
ugly, should be just for (int i=0; inames.length; i++){ final String
className = names[i];..}
Calling the class name 'word' is weird as well. (I do understand that's not
new but
Please disregard the remark about count, as any exception would make the
use of the index variable incorrect.
Stanimir
On Fri, Oct 10, 2014 at 6:10 PM, Stanimir Simeonoff stani...@riflexo.com
wrote:
persistentLoggers should be cleared on reset(), imo.
Also using count and then for in to loop
Hello,
Just a note, acc is going to leak the context class loader until the
listener is removed. That should be noted in the documentation.
Also if there is a runtime exception during run() of a listener it will
block any other listeners to be invoked and the exception is going to be
propagated
Good point. But I expect the concrete listener class will also be usually
loaded by the context class loader - so isn't that kind of expected anyway?
I didn't want to stuff too many implementation details into the spec.
Maybe that could be an API note however.
Would anyone be able to suggest
Hi Peter,
I like the LHM (personal favorite data structure) approach with the
dual-purpose key.
Stanimir
On Fri, Sep 12, 2014 at 2:55 PM, Peter Levart peter.lev...@gmail.com
wrote:
On 09/12/2014 12:45 PM, Daniel Fuchs wrote:
However the listeners are to be invoked in the same order they have
Hi Andrew,
On Wed, Sep 3, 2014 at 12:58 PM, Andrew Haley a...@redhat.com wrote:
On 03/09/14 01:15, Stanimir Simeonoff wrote:
Like David Lloyd mentioned finalize() can be invoked concurrently to
some methods (if there is no reachability to 'this'). OTOH I see
finalize useful for managing
I meant cleaning up rather than managing per se. To make it clear:
finalization is no substitute for proper lifecycle - anything that has
open() should have a following up close(), otherwise it's a bug.
Finalization still helps as safenet vs leaving native resources totally
unallocated and
Hi Jaroslav,
In my opinion the greatest downside of the finalize() is that involves
enlisting in a shared queue prior to the object creation. The queue is
shared amongst the entire VM and that could be a potential bottleneck.
In practical terms having a finalize method involves a full memory
Somewhat off topic.
The linked implementation of android lacks integer overflow on size. That
might be actually irrelevant on android due to OOM happening earlier than
integer overflow.
The latter that made me check the JDK impl. I know most concurrent
collections handle integer overflow (CLQ, CHM
Hi,
If there would be any changes to Deflater/Inflater I'd strongly suggest
enabling them to operate with direct buffers. Working with byte[] forces a
copy in the native code which is suboptimal.
Probably there should be a concern on memLevel for Deflate as well, iirc it
uses the 8 by default
java.util.logging.FileHandler uses ints to track the written bytes
that can cause negative value for
java.util.logging.FileHandler.MeteredStream.written as there is no
check in any of the write methods.
The overflow prevents the check in FileHandler.publish(LogRecord)
meter.written = limit to ever
Hi,
As the title says there is a major bug with HttpsURLConnection as it breaks
the contract of equals. So the instance cannot be contained (mostly
removed) in any collection reliably. (Concurrent)HashMap has a provision to
test equality by reference prior calling equals, though.
Finding the bug
Hi,
The real problem would be fields strikelist, graybits and the like not
inUse per se. They are not volatile either and there might not be proper
happens before edges, so they could easily be updated out of order. For
instance getGrayBits may throw a NPE.
IMO, inUse is overall a poor choice to
Hi Jaroslav,
The snippet is likely to just result into a NPE at obj.toString() than
anything else as obj must be a member and volatile to even compile.
Stanimir
On Fri, Aug 8, 2014 at 11:01 AM, Jaroslav Tulach jaroslav.tul...@oracle.com
wrote:
Hello Doug,
thanks for your reply and
Hi Peter,
Irrc, ServiceLoader.load(NameServiceDescriptor.class) uses
Thread.contextClassLoader to load the services. Depending how late the
NameServices is getting initialized, perhaps it can be used to circumvent
the loader available at clinit of InetAddress.
I am not sure it could be a real
44 matches
Mail list logo
