On 2019-03-15 19:06, Peter Levart wrote:
On 3/15/19 5:14 PM, Claes Redestad wrote:
Hi Peter,
thanks for reviewing!
Interning arbitrary attribute names might have some unfortunate side-
effects,
You mean if the number of different names would get larger and larger on
a long-running JVM,
On 3/15/19 5:14 PM, Claes Redestad wrote:
Hi Peter,
thanks for reviewing!
Interning arbitrary attribute names might have some unfortunate side-
effects,
You mean if the number of different names would get larger and larger on
a long-running JVM, the cache would grow without bounds?
I n
Hi Peter,
thanks for reviewing!
Interning arbitrary attribute names might have some unfortunate side-
effects, but a tiny - maybe one or two element - cache might be
sufficient to keep the churn low in practice.
Name and SHA1-Digest are the most commonly repeated non-constant
attribute, generat
Hi Claes,
If you have observed memory churn allocating Name objects when reading
jar files, then perhaps we could do something to the logic of Attributes
class so that lazily allocated Name(s) would get interned too?
As a separate change of course. This looks good as is.
Regards, Peter
On 3
On 15/03/2019 13:45, Claes Redestad wrote:
I have a solution to the heap dump issues out for review[1], so I've
cleaned up this patch, verified the failing tests pass locally and am
running both through tier1-3:
http://cr.openjdk.java.net/~redestad/8214712/open.01/
This version looks good
Hi,
On 2019-03-14 18:20, Claes Redestad wrote:
On 2019-03-14 18:13, Alan Bateman wrote:
For the current webrev then I'm concerned it is brings back legacy
attributes. The concept of "installed optional packages" was removed
in Java SE 9, as was the ability for JAR packaged applets to trigge
On 2019-03-14 18:13, Alan Bateman wrote:
On 14/03/2019 16:26, Claes Redestad wrote:
Hi,
this RFE was stalled due an interaction with SA that has since been
resolved. As it still applies cleanly I'll consider it reviewed. I'm
just going to do some sanity testing (tier1) before push.
I think w
On 14/03/2019 16:26, Claes Redestad wrote:
Hi,
this RFE was stalled due an interaction with SA that has since been
resolved. As it still applies cleanly I'll consider it reviewed. I'm
just going to do some sanity testing (tier1) before push.
I think we need to rollback some of the changes that w
Looks good!
Thanks,
Jiangli
On Thu, Mar 14, 2019 at 9:26 AM Claes Redestad
wrote:
> Hi,
>
> this RFE was stalled due an interaction with SA that has since been
> resolved. As it still applies cleanly I'll consider it reviewed. I'm
> just going to do some sanity testing (tier1) before push.
>
>
Hi,
this RFE was stalled due an interaction with SA that has since been
resolved. As it still applies cleanly I'll consider it reviewed. I'm
just going to do some sanity testing (tier1) before push.
Thanks!
/Claes
On 2018-12-03 17:02, Claes Redestad wrote:
Hi,
initializing java.util.jar.Attr
On 12/4/18 12:32 AM, Claes Redestad wrote:
These non-standard and tool/library specific names appear in the manifest of a
great many jar files, for example on maven central, and including the most
common non-standard manifest attributes significantly reduce allocation churn
reading such mani
On 2018-12-04 08:42, Alan Bateman wrote:
On 03/12/2018 16:50, Claes Redestad wrote:
:
The extra Names added to KNOWN_NAMES was my doing, and it was based
on commonly used attributes in Jar file manifests scanned from a set
commonly used applications as an alternative to building up a Name
Hi David,
unless my reading of JEP 334 (and JEP 303) is completely off then custom
constants (say, Attributes$Name) would effectively be turned into
condys, implying a bootstrap method call for them to be constructed. So
would carry similar construction overhead as the current implementation.
On 03/12/2018 16:50, Claes Redestad wrote:
:
The extra Names added to KNOWN_NAMES was my doing, and it was based on
commonly used attributes in Jar file manifests scanned from a set
commonly used applications as an alternative to building up a Name
cache dynamically (which is frought with oth
Hi Claes,
Meta-comment: are these Names candidates for the forthcoming
compile-time evaluation of constants? Just wondering if these
optimizations (and even the archiving itself) will be moot in the future?
Thanks,
David
On 4/12/2018 2:02 am, Claes Redestad wrote:
Hi,
initializing java.uti
Hi Claes,
Looks good from object graph archiving perspective. Placing the
KNOWN_NAMES map in the closed archive looks safe since no additional
names are added after initialization. If you also agree, maybe add a
comment above the KNOWN_NAMES field declaration with those information.
Thanks!
On 2018-12-03 17:06, Alan Bateman wrote:
On 03/12/2018 16:02, Claes Redestad wrote:
Hi,
http://cr.openjdk.java.net/~redestad/8214712/jdk.00/
This looks okay to me but the changes remind me that there are several
attributes name in KNOWN_NAMES are should probably be removed as they
aren'
On 03/12/2018 16:02, Claes Redestad wrote:
Hi,
initializing java.util.jar.Attributes.Name. executes ~20k
bytecodes setting up and eagerly calculating case-insensitive hash
codes for a slew of Name objects.
By archiving the resulting set of Names and initializing public
constants from the
Hi,
initializing java.util.jar.Attributes.Name. executes ~20k
bytecodes setting up and eagerly calculating case-insensitive hash codes
for a slew of Name objects.
By archiving the resulting set of Names and initializing public
constants from the archived map, we reduce time spent starting up
19 matches
Mail list logo
