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
wrote:
> Hi Joe, Peter, Paul
>
> This is the f
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 tra
>
>> 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
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 i
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 supp
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: fin
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 swit
> 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 jl
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 Syst
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 origina
>
> 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()/iterat
On Mon, Oct 27, 2014 at 12:36 AM, Peter Levart
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
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 on the default hashCode/equals of Method itself (hashCode ignores
the parameters). Possibly hashCode can include the returnType but equals
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
wrote:
> On 10/23/2014 01:57 AM, Stanimir Simeonoff wr
>>, UNSAFE.getObject(buffer, offsetOffset)
Obviously should be Unsafe.getInt(buffer, offsetOffset)
On Thu, Oct 23, 2014 at 11:16 AM, Stanimir Simeonoff
wrote:
> Unsafe is available, so the fields (array, offset) can be read directly
> UNSAFE.getObject(buffer, hbOffset), UNSAFE.getO
ArrayOffset(ByteBuffer bb) {
> if (bb.hasArray()) return bb.arrayOffset();
> if (bbArrayOffsetGetter != null) {
> try {
> return (int) bbArrayOffsetGetter.invokeExact(bb);
> } catch (Throwable e) {
> throw new
() : b.length;
> buffer.get(b, 0, length);
> update(b, 0, length);
> }
>
> 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 A
Class.java can easily be improved by adding an auxiliary HasMap 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 common case.
Alternati
On Thu, Oct 23, 2014 at 12:10 AM, Bernd Eckenfels
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 actually put a
eded to access CNFE
>>> package-private constructor from java.lang.ClassLoader, since they are in
>>> the same package, and from java.net.URLClassLoader, the call to
>>> super.findClass(name) does the job. So here's an updated webrev that also
>>> includes more desc
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 sh
; $ ./jdk1.8.0_20-b26_32bit/bin/java -showversion AddressSize
> java version "1.8.0_20"
> Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
> Java HotSpot(TM) Server VM (build 25.20-b23, mixed mode)
>
> Address Size: 4
>
> //Staffan
>
>
> On 10/17/2014 12:54 P
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 bool
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 =
ByteOrde
on to stay with the current implementation.
>
> Thanks,
> Staffan
>
>
> On 10/17/2014 10:06 AM, Stanimir Simeonoff wrote:
>
> Hi Staffan
>
> The actual "trick" is using ByteBuffer.asIntBuffer() while the address is
> properly aligned. It's not the most intuit
an updated webrev that also
> includes more descriptive message:
>
> 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 wr
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
a
On Tue, Oct 14, 2014 at 10:55 PM, Alan Bateman
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 updated webrev
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;
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
wrote:
> Hi all,
>
> please review this patch which attempts to clean up synchronization and
> improve scalability when
> defining and gettin
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
wrote:
> persistentLoggers should be cleared on reset(), imo.
>
> Also using "count" and
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; i
wrote:
> Hi,
>
> Please find below a possible fix for:
>
> 8060132: Handlers configured on abstract nodes in logging.properties are
> n
.fu...@oracle.com
> > To: stani...@riflexo.com
> > CC: jason_mehr...@hotmail.com; core-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, S
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 deleteAllLock
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
wrote:
> On 09/12/2014 12:45 PM, Daniel Fuchs wrote:
>
>> However the listeners are to be invoked in the same order they have been
>>> added.
>>
>
> 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 su
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 p
>
>
>>> 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
>>
Hi Andrew,
On Wed, Sep 3, 2014 at 12:58 PM, Andrew Haley 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
> > f
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 fence
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 (ma
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 wrote:
> Hello Doug,
> thanks for your reply and clarification about finalization
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 secu
I wonder why just don't use the /dev/random if available on *nix -
implemented by sun.security.provider.NativePRNG or
sun.security.mscapi.PRNG() on Windows that calls CryptGenRandom.
Both support SecureRandomSpi.engineGenerateSeed(int) that provides an
arbitrary amount of entropy.
Although the appr
48 matches
Mail list logo
