Quand on tape la commande java MaClass.java
Automatiquement la JVM met environ 750 classes en mémoire pour pouvoir l'exécuter.
Est-il possible que la JVM commence avec 0 classes et qu'elle les charge quand c'est nécessaire?
Merci
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
JVM désactivé le loading automatique au démarrage
Quand on tape la commande java MaClass.java
Automatiquement la JVM met environ 750 classes en mémoire pour pouvoir l'exécuter.
Est-il possible que la JVM commence avec 0 classes et qu'elle les charge quand c'est nécessaire?
Merci
C'est déjà le cas ; vois Consumer JRE: Leaner, Meaner Java Technology.
la preuve que non
tu le met dans un jar:
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
tu ajoute dans le manifest:
Code : Sélectionner tout - Visualiser dans une fenêtre à part jar -cvf test.jar SimpleMain.classtu exécute l'agent tout seul avec la commande:
Code : Sélectionner tout - Visualiser dans une fenêtre à part Premain-Class: SimpleMainrésultat 394 classes sont déjà lu dans la JVM
Code : Sélectionner tout - Visualiser dans une fenêtre à part java -javaagent:test.jar
De quelles classe s'agit il? Normalement il devrait seulement s'agir des classes nécessaire au fonctionnement de ton application.
C'est peut-être bête comme remarque, mais ce qu'il te retourne tient compte des classes chargées pour exécuter ton SimpleMain ? Si oui alors pour exécuter println() il doit charger quelques classes
il faudrait afficher les classes, mais vu que ta jvm est démarrée, t'as déjà toutes les classes associées au fonctionnement du GC qui doivent etre présente, toutes les classes liées à l'instrumentation, celles liées aux singletons System.out/err, indirectement celles liées aux classloader et l'exploration de jars, ...
Sans compter que ca prend vraisemblablement en compte les classes privées et les inner classes, qui foisonnent vite.
Quelque part, ce serait un peux comme s'étonner que pour charger les librairies et ton programme en C, le système a déjà fait 300 mallocs
Faudrais voir aussi si ta JVM est récente
voilà chez moi la liste des classes chargées:
Comme tu peux voir on y trouve:
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
-les types de bases
-l'instrumentation
-les classloader
-la sécurité car elle est utilisée par le classloader
-les charset(faut bien savoir écrire)
-des inner classes
-quelques collections
-tous les throwables déclarés par les classes utilisées
-des classes liées aux threads et la synchro
-les classes de sun
rien d'anormal en somme
J'ai 349 classes chargées. Si je fais un SimpleMain.class.forName("javaw.swing.JFrame"), je passe à 451, soit une centaines de classes chargées juste pour accéder à JFrame, et ca met un quart de poil de seconde
ok merci pour vos réponses
Donc moi mon but c'est de faire de l'instrumentation de classe au moment ou elles sont chargées mais avant que j'ai le temps de les instrumenter, elles sont déjà chargées dans la JVM.
Est ce que quelqu'un a une idée pour instrumenter les classes déjà chargées.
l'étape d'après dans mon SimpleMain c'est :
instrumentation.addTransformer(new SimpleTransformer( ) );
Transformer une classe déjà lue
Voila le ClassFileTransformer qui modifie toutes les classes qui sont lue par la suite.
J'imagine que c'est l'instruction super() de mon constructeur qui fait chargé 350classes d'un coup.
Enfin c'est inévitable donc il faut que je fasse un retransform sur les classes déjà lu.
Donc évidement ca fonctionne pas. Le code
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
au début de la méthode public byte[] transform( ... ) m'indique le nom des classes qui sont modifiées mais les classes déjà lues ne passe pas par cette méthode malgré le
Code : Sélectionner tout - Visualiser dans une fenêtre à part System.out.println("Modifying: " + className);fait dans le constructeur du ClassFileTransformer
Code : Sélectionner tout - Visualiser dans une fenêtre à part instrum.retransformClasses(cl[a]);
Salut,
Il ne manquerait pas un Can-Retransform-Classes ou un Can-Redefine-Classes dans ton manifest ???
Source : http://javasearch.developpez.com/j2s...e-summary.html
a++
très bonne remarque
merci
effectivement avec :
dans le manifest ca fonctionne mieux. Merci pour l'info
Code : Sélectionner tout - Visualiser dans une fenêtre à part Can-Retransform-Classes: true
Mais je n'arrive toujours pas a instrumenter les classes :
java/lang/String
java/lang/Integer
etc ...
Est ce qu'il y a un moyen?
De plus, lors de mon premier test : instrum.isModifiableClass(cl[a])
Les classes String etc ... se disent modifiable.
Quelqu'un a une idée
j'arrive en modifier 16 sur 300
grace à
Can-Retransform-Classes: true
dans le manifest je retransform 16 classes sur les 300 chargés au démarrage.
peut être faut-il fait carrément faire un
Instrumentation. redefineClasses(ClassDefinition[] definitions)
le probleme c'est pour le ClassDefinition :
public ClassDefinition(Class<?> theClass, byte[] theClassFile)
- Creates a new ClassDefinition binding using the supplied class and class file bytes. Does not copy the supplied buffer, just captures a reference to it.
Parameters:
theClass - the Class that needs redefining
theClassFile - the new class file bytes
pour avoir le byte[] "theClassFile" il faut que j'appel la méthode transform qui me permet d'avoir un nouveau byte[] qui est en fait ma classe instrumenté.
mais seulement le transform il faut lui donner tout ces paramètres :
Et je sais pas comment faire
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
Erreur
désolé en fait le fait de rajouter l'option ne m'a rien fait gagner.
J'ai commenté le code instrum.retransformClasses(cl[a]);
et ca me donne le même résultat.
Je n'ai toujours pas réussir à retransformer les classes déjà lu par la JVM.
Pourtant je suis sure que c'est possible
Proposition qui fonctionne presque
voila ce que j'ai décidé de faire:
au lieu de faire un retransform je fais un redefine.
seulement je n'arrive pas lui envoyer le dernier paramètre
classfileBuffer - the input byte buffer in class file format - must not be modified
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager